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1 .  Overview 

Traditionally,  visualization  of  software  has  been  ineffective  for  the  development  cycle 
due  to  the  long  turnaround  time  to  create  visualizations  that  are  relevant  to  both  the  level 
of  abstraction  and  domain-specificity  that  the  software  developer  is  working  with  at  any 
given  time.  The  "post-mortem"  approach  of  creating  visualizations  by  hand  after 
development  of,  say  a  data  structure,  necessitates  a  loss  of  time  and  money  when  the  data 
structure  changes  and  the  visualization  has  to  be  redone.  Also,  errors  could  be  introduced 
in  such  a  manual  visualization  process.  We  believe  that  the  Knowledge-Based  Software 
Assistant  (KBSA)  "machine-in-the-loop"  approach  [GLB+86,GRW96]  can  be  extended 
to  the  area  of  software  visualization,  and  thereby  remove  the  stumbling  blocks  of  slow 
turnaround  time  and  human  error.  Seen  in  the  KBSA  light,  visualization  is  not  a  process 
that  occurs  "after  the  fact."  Rather,  like  validation,  visualization  is  co-derived  with 
software  and  maintained  similarly. 

We  have  done  research  and  have  implemented  an  experimental  prototype  system  to  meet 
the  goal  of  automatically  producing  visualizations  of  software  entities,  such  as  abstract 
data  types.  The  approach  we  have  taken  is  analogous  to  the  approach  we  have  taken  in 
the  past  for  automated  derivation  of  algorithms  fi'om  specifications:  begin  with  a  formal 
description  of  the  entity  to  be  visualized,  and  repeatedly  apply  automated  inference  steps 
to  transform  the  description  into  a  form  which  can  be  rendered  via  standard  techniques. 
The  implementation  is  being  created  using  our  latest  system  for  software  design  and 
development,  called  Specware,  built  using  KBSA  technology.[JS93,JS95] 

In  this  report,  we  document  our  experiences  using  Specware  to  construct  formal 
specifications  for  data  visualization.  This  report  is  organized  as  follows: 

•  Section  2  provides  a  conceptual  overview  of  the  VIZO  system; 

•  Section  3  provides  an  overview  of  the  VIZO  system; 

•  Section  4  describes  a  sample  visualization; 

•  Section  5  describes  the  VIZO  system  in  greater  detail; 

•  Section  6  describes  the  role  of  sound  in  vizualization; 

•  Section  7  contains  a  summary  of  this  research; 

•  Appendix  A  contains  a  more  detailed  example;  and 

•  Appendix  B  describes  the  Specware  system  in  greater  detail. 

2.  Visualization  via  Abstract  Views  Enables  Automation 

One  of  the  roadblocks  that  most  visualization  systems  encounter  in  achieving  automation 
is  the  variety  of  different  types  of  entities  that  may  potentially  be  represented  crossed 
with  the  variety  of  potential  ways  to  represent  them.  This  leads  to  one  of  two  approaches: 
either  attempt  to  pre-anticipate  as  many  solutions  as  possible  (which  inevitably  restricts 
the  range  of  applicability  to  a  narrow  domain),  or  require  the  human  to  do  the  work  of 
visualization  with  a  set  of  base  tools  provided  by  the  system. 
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View 


Figure  1.  Relation  between  View,  Rendering  and  Data 

Our  approach  begins  with  the  separation  of  the  visualization  process  into  two  steps.  First, 
categorize  the  entity  being  visualized  (call  this  the  "data"  for  convenience,  though  it  may 
in  general  be  a  process  which  will  become  animated)  as  an  instance  of  an  abstract  "view" 
or  “pattern”.  Then,  using  the  inference  process  described  in  Section  3,  transform  the  view 
into  a  "rendering"  which  reflects  the  properties  of  the  view.  Figure  1  shows  the 
relationship  between  the  data,  view  and  rendering  for  a  small  abstract  datatype  (a  set  of 
pairs).  In  the  case  of  Figure  1,  the  entity  being  visualized  is  categorized  as  a  set  of  tuples 
and  two  renderings  are  shown  for  these  tuples. 

Notice  that  the  same  view  can  have  multiple  renderings,  and  although  it  is  not  depicted, 
the  same  data  may  have  different  views.  Views  can  be  combined  and  manipulated 
automatically  because  they  are  formally  described  (i.e.,  their  properties  are  made  explicit) 
in  the  logical  framework  of  Specware.  This  approach  reduces  the  necessary  pre¬ 
anticipated  constructs  to  the  small  set  of  independent  visualization  concepts  needed  to 
make  a  complex  visualization  (e.g.  adjacency,  containment),  enabling  automation  to  take 
place.  Figure  2  shows  a  partial  hierarchy  of  aggregate  views  which  can  be  built  using  the 
more  basic  views. 
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Hierarchies  such  as  this  are  common  in  the  Specware  framework,  and  enable  the 
incremental  refinement  of  one  view  into  another  (working  down  the  hierarchy), 
eventually  ending  up  with  a  "renderable"  description  of  the  desired  data.  Once 
automated,  a  human  can  then  choose  between  different  alternative  renderings  of  the  data, 
depending  on  the  task  at  hand.  Novel  visualizations  result  from  the  combination  of  views 
that  previously  have  not  been  combined.  For  example,  Gantt  and  DAG  views  can  be 
combined  to  form  hybrid  dependency/timing  diagrams. 


3.  VIZO  Architecture:  Overview 

The  prototype  VIZO  system  attempts  to  realize  the  preceding  model  of  automatic 
visualization  construction.  The  VIZO  architecture,  seen  below,  shows  the  visualization 
process  at  a  high-level  overview. 
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Figure  3.  VIZO  Architecture 


Notice  the  "data"  and  abstract  "view"  in  the  two  boxes  in  the  upper-left  part  of  the 
diagram  map  directly  to  the  data  and  view  firom  Figure  3.  The  final  "rendering"  appears 
in  the  box  in  the  lower-right.  The  boxes  and  arrows  between  the  view  and  the  rendering 
depict  the  automated  reasoning  process  which  results  in  a  visual  representation  of  the 
data.  In  VIZO,  two  types  of  automated  reasoning  occur.  The  first  is  called  refinement,  a 
process  that  is  based  on  an  automated  theorem  proving  engine  and  is  directly  supported  in 
Specware.  The  second  is  the  use  of  specialized  constraint  solvers.  Both  of  these 
processes  and  the  roles  they  play  are  discussed  below. 


3.1.  Refinement 

Refinement  is  a  formal  operation  in  Specware  in  which  an  interpretation  is  created  from 
one  view  to  another,  allowing  any  data  which  can  be  described  using  the  first  view  to  also 
be  described  using  the  second  view.  Typically,  interpretations  are  used  to  map  abstract 
entities  into  concrete  implementations,  such  as  mapping  the  sorts  and  operations  of  a  Set 
abstract  data  type  (ADT)  into  the  sorts  and  operations  of  a  List  ADT.  In  the  visualization 
domain,  given  a  view  which  describes  the  data  abstractly  as  a  related  pair  of  regions  (on 
the  screen),  there  is  an  interpretation  which  maps  this  view  into  a  more  refined  view  in 
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which  pairs  of  related  regions  become  ovals  connected  with  a  line  between  them.  In  this 
example  the  concept  of  an  amorphous  "region"  is  refined  to  a  specialized  instance  of  a 
region,  namely  an  oval.  Similarly,  the  concept  of  two  regions  being  "related"  is  refined  to 
a  specialized  representation  of  the  relation,  namely  being  connected  with  a  line.  An 
alternate  refinement  for  the  same  original  view  is  that  of  a  pair  of  adjacent  boxes.  Figure 
4  shows  how  refinements  are  used  to  transform  a  set  of  pairs  of  numbers  into  a  table 
which  can  be  rendered  on  the  screen. 

Notice  that  in  several  places  (i.e.  the  two  ordering  steps  and  the  two  adjacency  steps), 
existing  refinements  were  used  in  different  contexts.  This  is  one  example  of  how  our 
approach  eliminates  the  need  to  pre-anticipate  solutions  in  order  to  cover  the  space  of 
useful  visualizations. 


3.2.  Constraint  Solving 

The  result  of  the  refinement  process  is  a  formal  description  that,  given  a  graphics  system 
with  primitive  operations  that  match  those  in  the  description,  can  be  directly  rendered. 
Often  times  it  is  desirable  that  the  output  of  the  refinement  leave  certain  layout  decisions 
uncommitted,  allowing  multiple  solutions  which  are  consistent  with  the  current  view. 

For  instance,  the  view  may  specify  that  two  objects  be  aligned  on  their  top  boundary,  but 
it  may  not  matter  how  close  they  are  in  the  horizontal  dimension.  In  such  a  case  there  are 
many  possible  final  renderings  which  are  consistent  with  the  current  view.  The 
remaining  task  is  to  determine  where  to  place  both  objects  on  the  screen  subject  to  the 
constraint  that  the  top  boundaries  align  (and  possibly  subject  to  other  constraints  as  well). 
Here,  we  employ  a  constraint  solver  to  determine  a  consistent  or  optimal  solution.  Figure 
5  shows  several  of  the  constraints  which  commonly  arise  in  visualization,  depicted  by 
example. 

Constraint  solvers  are  automated  reasoning  engines,  similar  to  automated  theorem 
provers,  though  they  are  usually  tailored  to  a  specific  domain  of  discourse  (such  as 
integer  linear  systems  of  equations).  Because  of  this,  they  can  be  made  very  efficient  for 
the  class  of  problems  they  address.  The  match  between  the  kinds  of  constraints  we  need 
to  solve  in  VIZO  and  the  traditional  domains  of  constraint  solvers  (i.e.  numerical)  is  a 
good  one.  We  have  explored  several  freely  available  constraint  solvers:  SkyBlue, 

Omega,  and  an  implementation  of  a  solver  described  in  Guy  Steele's  doctoral  dissertation. 
Omega  is  currently  integrated  into  our  theorem  prover.  While  each  of  these  systems  may 
be  made  to  work  with  the  VIZO  system,  we  feel  that  better  constraint-solving  technology 
-  one  handling  more  complex  and  aggregate  constraints  -  will  greatly  aid  the  system,  and 
furthermore,  such  technology  is  likely  to  be  built  within  the  next  few  years  as  the 
importance  of  constraint-based  reasoning  is  being  recognized  in  the  larger  community. 
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Figure  4.  Refinement  Example 

In  addition,  Kestrel  has  technology  to  synthesize  highly-efficient  constraint  solving 
algorithms  for  the  domain  of  scheduling.  [Smith93]  We  believe  that  our  techniques  will 
carry  over  to  allow  us  to  synthesize  similar  algorithms  for  constraint  solving  in  two  or 
three  dimensions  (scheduling  is  an  instance  of  constraint  solving  in  one  dimension,  i.e. 
time),  which  is  ideal  for  rendering  in  two  or  three  dimensions.  The  high  speed  of  the 
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synthesized  constraint  solvers  is  a  result  of  "compiling"  some  or  all  of  the  constraints  into 
the  solver,  so  that  the  result  is  a  very  efficient  algorithm  specialized  for  the  problem  at 
hand.  We  believe  this  holds  promise  for  automating  the  constraint  solving  aspects  of  the 
visualization  process. 
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Figure  5.  Visualization  Constraint  Examples 


4.  Using  Automated  Visualization  Interactively 

Thus  far  we  have  discussed  VIZO  in  the  context  of  a  fully  automated  visualization 
synthesis  engine,  which  might  be  part  of  a  larger  system  (e.g.  for  software  development). 
We  believe  automated  visualization  can  and  should  be  used  in  interactive  contexts  as 
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well.  The  incremental  refinement  approach  taken  in  VIZO  leads  to  a  natural  substrate  for 
supporting  a  human-directed,  machine-driven  visualization  system.  By  factoring  out  the 
visualization  design  decisions  into  independent,  composable  views,  the  VIZO  approach 
allows  for  the  creation  of  a  visualization  system  where  the  human  can  try  out  various 
techniques  very  rapidly  by  choosing  which  view  to  apply  next,  while  the  machine  carries 
out  the  task  of  actually  applying  the  view.  The  following  domain-specific  visualization 
scenario  illustrates  this  point. 


4. 1.  Visualization  Example 

Scenario:  a  task  force  command  center  has  been  set  up  to  control  a  rash  of  fires  that  have 
broken  out  in  the  hills  surrounding  a  city.  The  command  center  receives  reports  of  the 
various  fires  over  communication  links  with  helicopter  and  ground  crews  throughout  the 
area.  The  reports  are  varied  in  the  type  and  amount  of  information  that  they  give,  and 
they  are  constantly  changing.  The  commander  wants  to  get  an  assessment  of  the  overall 
situation  and  decides  to  concentrate  on  three  pieces  of  information  from  each  report:  (1) 
the  fire’s  position,  (2)  its  size,  and  (3)  its  percent  containment.  Figme  6  shows  the 
process  that  occurs,  with  each  rounded  box  corresponding  to  the  intermediate 
visualizations  that  are  explored  in  this  process. 

The  initial  visualization  in  (b)  is  a  simple  table  generated  using  the  three  types  of  data 
described  in  (a).  In  (c),  the  users  are  able  to  see  visually  where  the  fires  are  in  relation  to 
each  other  because  the  position  of  the  fires  are  mapped  to  positions  on  the  screen.  This 
view  is  refined  further  in  (d),  where  size  of  the  fire  determines  the  scale  of  the 
representation,  and  in  (f),  where  the  fires  themselves  are  changed  from  a  textual 
representation  to  a  graphical  one  (a  circle),  with  shading  indicating  the  current 
containment  level.  At  this  point  the  users  determine  that  a  different  approach  would  be 
more  illuminating,  so  the  visualization  is  rederived  starting  with  (c)  and  arriving  at  (e), 
where  the  containment  percentage  is  proportional  to  the  scale  factor,  and  size  determinant 
of  the  shading,  but  this  time  with  a  legend  to  explain  the  shading.  Still,  the  visualization 
could  be  made  better  suited  to  the  task  at  hand,  since  the  fires  that  are  well  contained  are 
depicted  as  larger  and  the  fires  that  are  poorly  contained  are  depicted  as  smaller.  Thus, 

(g)  rectifies  the  situation  by  inverting  the  relationship  between  scale  factor  and 
containment  percentage,  so  that  poorly-contained  fires,  which  are  deserving  of  more 
attention,  appear  more  prominently  in  the  display.  Finally,  (i)  shows  a  composition  of  the 
two  views  in  (g)  and  (h).  Notice  that  this  is  not  a  simple  overlay  of  renderings  (in  which 
the  street  names  would  overlap  the  fires),  but  rather  a  composition  of  the  two  views,  fi'om 
which  a  final  rendering  is  generated. 
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Figure  6.  Domain-Specific  Visualization  Generation  Example 
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4.2.  Maintaining  Direct  Connection  Between  Data  and  Visuaiization 


The  VIZO  approach  has  an  additional  advantage  in  supporting  interactive  visualization  in 
that  the  connections  between  the  individual  objects  on  the  screen  rendering  and  the  data 
that  they  represent  can  be  explicitly  maintained  through  the  view.  This  allows  for  the 
creation  of  an  interface  in  which  both  the  data  and  the  rendering  can  be  manipulated  by 
the  user,  and  the  other  will  be  updated  correspondingly. 


5.  The  VIZO  Prototype  System:  In  Detail 

The  Specware  system  described  in  Appendix  B  is  designed  to  facilitate  composition  of 
complex  software  constructs  through  the  use  of  fundamental  mathematical  operations,  in 
particular  those  from  category  theory  and  sheaf  theory.  We  have  endeavored  to  use  a 
consistent  design  philosophy  throughout  the  implementation  of  Specware,  so  that  all  its 
components  achieve  a  natural  interface  to  the  core  system,  sharing  common  abstract 
structures  and  methods  as  much  as  possible. 

For  example,  the  same  basic  paradigm,  and  much  of  the  same  code,  is  used  when 
transforming  abstract  specifications  into  detailed  specifications,  when  communicating 
with  a  theorem  prover,  and  when  translating  specifications  into  code.  An  interesting 
challenge  has  been  to  achieve  this  same  kind  of  seamless  interface  for  a  visualization 
system. 

The  approach  we’ve  explored  starts  with  a  triangle  model  as  depicted  in  Figure  7,  which 
is  an  elaboration  of  that  shown  in  Figure  1.  We  decompose  the  structure  of  a  graphical 
depiction  into  three  main  components:  the  data  to  be  viewed,  the  view/pattem  we  seek  in 
the  data,  and  the  graphics  used  to  render  such  patterns.  Each  of  the  three  components  is 
modeled  with  a  Specware  specification,  and  the  two  arrows  connecting  the  pattern  to  data 
and  pattern  to  graphics  are  modeled  with  Specware  interpretations. 

In  all  of  the  examples  to  follow,  the  data  specification  is  assumed  to  be  some  possibly 
complex  specification  describing  a  scheduling  domain  with  operations  on  it.  The  pattem- 
to-data  or  “viewing”  interpretation  projects  an  image  of  the  pattern  specification  into  a 
definitional  extension  of  the  data  specification,  i.e.,  into  an  extension  that  merely  gives 
names  to  some  terms  already  implicitly  present  in  the  data  specification.  It  is  also  correct 
to  think  of  the  view  interpretation  as  locating  the  pattern  in  the  data. 

The  pattern  specification  will  vary  from  example  to  example,  although  it  is  both 
convenient  and  reasonable  to  assume  it  is  constructed  from  basic  set  theoretic  structures 
such  as  numbers,  sets,  sequences,  relations,  maps,  etc. 
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VISUALIZATION  MODEL 


RENDERING 


Figure  7 


The  structure  of  the  graphics  specification  will  depend  on  the  approach  chosen,  as 
explained  below,  but  it  includes  abstract  data  types  for  entities  such  as  points,  lines, 
boxes,  colors,  and  dimensions.  The  pattem-to-graphics,  or  rendering,  interpretation  maps 
the  pattern  into  graphical  terms,  effectively  showing  how  to  depict  such  a  pattern. 

At  this  point,  not  worrying  about  the  details,  we  could  consider  taking  the  colimit  of  the 
diagram  shown  in  Figure  7,  combining  all  of  the  sorts  and  operations  from  both  the  data 
specification  and  the  graphics  specification.  However,  that  would  put  all  of  the 
significant  structure  down  inside  one  composite  specification,  effectively  hiding  it  from 
observation  and  manipulation  by  higher  level  Specware  operations. 

A  better  approach  is  to  notice  that  if  specifications  are  viewed  as  topoi,  which  are  a  kind 
of  category,  then  interpretations  become  fimctors,  which  are  a  kind  of  structure 
preserving  map  from  one  category  to  another,  which  means  that  given  a  diagram  as  in 
Figure  7,  we  can  construct  natural  transformations,  which  are  a  kind  of  morphing  of  one 
functor  into  another  (or  alternatively,  a  kind  of  homomorphism  between  specified 
portions  of  specifications).  This  more  elaborated  view  is  shown  in  Figure  8. 
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ELABORATED 
VISUALIZATION  MODEL 


NATURAL 
TRANSFORMATION 
(PARTIAL  HOMOMORPHISM) 


Figure  8 


Figure  9  shows  a  simple  example  to  make  this  more  clear.  The  pattern  specification 
contains  an  abstract  operation  called  NatValue  that  maps  Thing  to  Nat,  and  the  pattem-to- 
data  interpretation  maps  this  NatValue  operation  onto  a  Duration  operation  defined  on 
schedules.  The  rendering,  or  pattem-to-graphics,  leg  of  the  triangle  could  also  be  modeled 
entirely  within  Specware  as  a  simple  interpretation.  In  that  case  the  rendering 
interpretation  would  map  NatValue  into  something  like  ColorValue  (BarValue, 
TextValue,  etc.),  defined  in  the  graphics  specification,  mapping  Thing  to  Color  (Bar, 

Text,  etc.),  as  shown  in  Figure  9.  The  natural  transformation  then  consists  of  an 
isomorphism  mapping  Duration  onto  ColorValue,  Schedule  onto  Thing,  Nat  onto  Color, 
etc. 


Simple  Example 


PATTERN 
NatValue :  Thing  •>  Nat 


Duration  :  Schedule  •>  Nat 

defined  using 
operations  in 

SCHEDULE 


ColorValue :  Thing  ->  Color 

defined  using 
operations  in 

GRAPHICS 


Figure  9 
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Unfortunately,  an  undesirable  side  effect  of  this  approach  is  that  the  rules  for  constructing 
specification  morphisms  (which  require  specification  morphisms  to  be  total  functions) 
would  require  the  target  Color  sort  to  include  the  structure  of  the  natural  numbers,  e.g.  to 
have  ColorZero,  ColorPlus,  etc.  In  general,  that  probably  requires  too  much  structure  on 
the  target  sorts,  but  with  the  approach  described  so  far,  the  only  way  to  eliminate  some  of 
that  structure  would  have  been  to  simplify  the  pattern,  and  that  works  contrary  to  desire 
for  the  view  and  rendering  interpretations  to  be  orthogonal. 

A  better  approach  is  shown  in  Figure  10,  where  we  have  connected  multiple 
view/rendition  triangles  to  effectively  break  the  depiction  into  steps.  In  the  first  step,  we 
use  the  unrestricted  pattern  specification,  and  the  rendering  interpretation  maps  Nat  into 
an  abstract  graphics  numeric  sort  that  subsequent  depictions  will  specify  as  a  bar,  color, 
sequence  of  digits,  etc.  Note  that  both  natural  transformations  describe  isomorphisms, 
but  the  second  (on  the  right)  is  an  isomorphism  on  less  structure  than  the  one  on  the  left, 
since  it  merely  preserves  the  structure  of  a  total  order,  whereas  the  natural  transformation 
on  the  left  preserves  the  more  detailed  structure  of  the  natural  numbers. 

FACTORED  DEPICTION 


NAT 

PATTERN 


TOTAL  ORDER 
PATTERN 


NatValue 


TotalOrderValue 


/  \  /  \ 


SCHEDULE 

ABSTRACT 
^  GRAPHICS  ^ 

COLOR 

GRAPHICS 

Duration 

NumberValue 

ColorValue 

Figure  10 


Since  the  triangles  can  be  composed  (side  by  side)  and  an  identity  triangle  is  easy  to 
construct,  we  can  view  these  triangles  as  arrows  in  a  depiction  category,  as  shown  in 
Figure  11.  The  abstract  structure  of  an  arrow  in  this  category  is  quite  general,  essentially 
identifying  a  homomorphism  from  part  of  one  specification  into  part  of  another,  so  it 
seems  like  a  good  candidate  to  add  to  the  general  toolkit  available  in  Specware, 
independent  of  its  use  for  visualization.  This  is  a  good  sign  and  addresses  the  abstract 
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concern  expressed  above  for  an  elegant  integration  with  the  core  Specware  system.  In 
particular,  note  that  accurate  and  useful  rendering  of  data  involves  a  lot  of  structure 
preservation,  and  we've  managed  to  keep  most  or  all  of  that  regular  mapping  out  at  the 
inter-specification  level  where  generic  Specware  tools  can  manipulate  it  (as  opposed  to 
burying  it  within  a  single  specification  in  some  monolithic  presentation).  This  accords 
well  with  our  goal  of  integrating  graphical  operations  with  fundamental  Specware 
structures. 


DEPICTIONS  AS  ARROWS 


PATTERN  PATTERN  PATTERN 

/^\  /^\ 

DATA  - ►GRAPHICS  ^ - ►GRAPHICS  - ►GRAPHICS 

EACH  TRIANGLE  BECOMES  AN  ARROW 
IN  THE  NEW  CATEGORY  OF  DEPICTIONS 

DATA  . ►  GRAPHICS  —#►  GRAPHICS  GRAPHICS 


Figure  11 


This  division  of  depiction  into  concatenated  steps  provides  additional  benefits. 
Conceptually,  it  allows  us  to  factor  the  depiction  into  one  phase  that  casts  the  structure 
under  consideration  into  abstract  graphical  terms,  and  subsequent  phases  that  project 
those  abstract  terms  into  physically  realizable  ones. 

Figure  12  shows  this  division  for  a  slightly  more  complicated  example  in  which  the 
pattern  is  a  sequence  of  intervals.  The  abstract  graphical  specification 
Abstract_Dimensions  introduces  the  notiou  of  an  abstract  dimension,  which  has  sufficient 
strueture  to  be  a  good  target  for  intervals,  sets,  sequences,  tuples,  relations,  maps,  and 
many  other  set  theoretic  structures.  The  first  depiction  arrow  effectively  maps  the  desired 
pattern  into  a  high  (in  this  simple  case,  two)  dimensional  space,  then  subsequent  arrows 
project  that  space  down  into  something  renderable  in  real  dimensions  for  space,  time, 
color,  etc. 
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DEPICTION  IN  TWO  STEPS 


SEGMENT<->  D2  D2  <->  Y-AXIS 


Figure  12 


Using  an  abstract  dimensional  space  as  the  first  depiction  target  has  good  computational 
and  user  interface  properties.  It  allows  us  to  automate  the  subsequent  depictions  with  a 
graphical  engine  that  can  produce  the  effect  of  what  could  be  done  with  standard 
Specware  tools,  but  in  an  optimized  manner  that  avoids  the  overhead  of  reifying  as  much 
structure,  and  under  a  specialized  user  interface  that  allows  the  user  to  project  dimensions 
interactively  through  menus  without  wonying  about  the  details  of  constructing  actual 
depiction  arrows. 

To  show  how  this  technology  could  be  developed  synergistically  with  the  scheduling  and 
architecture  projects  underway  at  Kestrel,  a  simple  project  demo  involving  scheduling 
data  was  constructed  and  given  following  the  1996  Knowledge-Based  Software 
Engineering  (KBSE)  conference.  The  effect  was  to  show  in  principle  how  this  model 
could  be  used  to  construct  a  Gantt  chart  from  scheduling  data. 

To  understand  how  a  realistic  picture  such  as  a  Gantt  chart  might  be  constructed,  we 
consider  a  somewhat  more  elaborate  example.  Now  the  data  are  a  schedule,  as  in  Figure 
7,  but  the  pattern,  whose  top  level  structure  is  shown  in  Figure  13,  is  a  tuple  of  a  string 
(the  schedule-name)  and  a  set  (of  scheduled  assets)  whose  elements  are  tuples  of  strings 
(asset  names)  with  a  sequence  (of  trips)  whose  elements  are  tuples  of  a  string  (a  trip 
description)  with  a  sequence  (of  trip  segments)  whose  elements  are  tuples  of  a  element 
from  a  finite  set  (loading,  flying,  etc.)  and  an  interval  in  time.  (See  Appendix  B  for 
details  concerning  the  specification  language  Slang  used  in  Figures  13  &  14.) 
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specification  Pattern-for-Schedule  is  colimit  of 
diagram 

nodes  Labeled- Intejrval , 

Trivl  :  Triv,  Labeled-Set-1  :  Labeled-Set, 

Triv2  :  Triv,  Labeled-Set-2  :  Labeled-Set, 

Triv3  :  Triv,  Labeled-Set-3  :  Labeled-Set 
arcs  Trivl  ->  Labeled-Interval  :  {E  ->  Labeled-Interval} , 
Trivl  ->  Labeled-Set-1  :  {E  ->  Set-Elt) , 

Triv2  ->  Labeled-Set-1  :  {E  ->  Labeled-Set) , 

Triv2  ->  Labeled-Set-2  :  {E  ->  Set-Elt}, 

Triv3  ->  Labeled-Set-2  :  {E  ->  Labeled-Set}, 

Triv3  ->  Labeled-Set-3  :  {E  ->  Set-Elt} 

end-diagram 


Figure  13 

The  first  depiction  triangle  was  instantiated  with  a  pair  of  interpretations,  each  of  which 
was  constructed  using  standard  Specware  tools  from  smaller  component  interpretations 
similar  to  the  two  shown  in  Figure  14. 


Interpretation  View-Trip-Segment-As-Labeled-Interval 
:  Labeled- Interval  =>  Trip-Segment  is 
mediator  Trip-Segment 

domain- to-mediator  {Labeled-Interval  ->  Trip-Segment} 

codomain-to-mediator  identity-morphism 

Interpretation  View-Trip-As-Labeled-Set-of-Labeled-Intervals 
:  Labeled-Set  =>  Trip  is 
mediator  Trip 

domain- to-mediator  {Labeled-Set  ->  Trip} 

codomain-to-mediator  identity-morphism 


Figure  14 


The  primary  pattem-to-graphics  interpretation  mapped  tuples,  sequences,  strings,  etc.  in 
the  pattern  onto  various  kinds  of  virtual  dimensions  in  a  graphics  specification.  Then  a 
prototype  version  of  the  user-interface  code  was  used  to  dynamically  assign  virtual 
dimensions  to  real  dimensions,  as  explained  next. 

For  this  example,  we  generated  18  such  dimensions,  as  follows: 


D1 

D2 

D3,  D4 
D5 
D6 
D7 

D8,  D9 

DIO 

Dll 


schedule 
schedule  name 
character  region 
scheduled  assets 
scheduled  asset 
asset  name 
character  region 
trips 
trip 


two  element  tuple  of  <D2,  D5> 

sequence  over  D3  x  D4 

two  orthogonal  finite  dimensions 

sequence  over  D6 

two  element  tuple  of  <D7,  D10> 

sequence  over  D8  x  D9 

two  orthogonal  finite  dimensions 

sequence  over  Dll 

two  element  tuple  of  <D12,  D15> 
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D12  :  trip  description  :  sequence  over  D13  x  D14 

D13,  D14  :  character  region  :  two  orthogonal  finite  dimensions 

D15  :  trip  segments  :  sequence  over  D16 

Die  :  trip  segment  :  two  element  tuple  of  <D17,  D18> 

D17  :  segment  status  :  finite  set  {loading,  flying,  unloading} 

D18  :  segment  duration  :  interval  in  time 

There  are  properties  on  individual  virtual  dimensions,  and  constraints  among  the  virtual 
dimensions.  For  example,  the  virtual  dimensions  used  for  sequences  must  be  mapped 
onto  real  dimensions  with  extent,  e.g.,  space  or  time  but  not  color,  whereas  dimensions 
that  represent  a  single-valued  attribute  such  as  D17  (segment  status)  are  allowed  to  map 
onto  almost  any  dimension:  space,  time,  color,  a  set  of  patterns,  etc.  Since  dimensions 
D3  and  D4  form  a  character  plane,  they  must  map  to  a  pair  of  real  dimensions  that  are 
orthogonal  to  each  other,  but  it  is  allowed  (even  preferable)  for  both  D3  and  D18  to  map 
to  the  same  real  X  dimension. 

The  rendering  engine  interacts  with  the  user  to  map  a  set  of  virtual  dimensions  into  real 
dimensions,  after  which  the  data  are  automatically  displayed  according  to  that  format. 

The  user  can  then  change  this  mapping  indefinitely,  occasionally  asking  for  the  data  to  be 
redisplayed  in  whatever  format  is  current. 

Because  the  number  of  real  dimensions  is  quite  limited,  we  need  to  use  rules,  heuristics, 
and  user  guidance  to  consistently  and  effectively  map  the  myriad  virtual  dimensions 
down  to  the  available  real  dimensions.  There  are  several  strategies  we  can  employ.  One 
is  to  increase  the  number  of  available  real  dimensions,  a  second  is  to  hyperlink,  a  third  is 
to  collapse  redundant  dimensions,  a  fourth  is  to  tile  one  virtual  dimension  within  another, 
and  a  fifth  is  to  allow  the  option  of  simply  ignoring  some  dimensions.  These  five 
approaches  are  described  in  the  following  paragraphs.  There  could  be  other  such 
strategies— this  is  not  meant  to  be  an  exhaustive  list. 

Adding  more  real  dimensions  is  not  as  difficult  as  it  sounds.  Since  many  of  the  virtual 
dimensions  we  need  to  map  represent  small  finite  sets,  even  small  sets  of  visually  distinct 
attributes  can  be  exploited  to  add  new  dimensions.  For  example,  in  addition  to  X,  Y,  and 
Z  spatial  dimensions,  we  can  include  color  dimensions  such  as  hue  or  intensity,  or 
dimensions  that  consist  of  a  set  of  distinguished  patterns.  In  the  example  above,  we  could 
map  dimension  D17  [loading,  flying,  unloading]  onto  colors  [blue,  red,  green]  or  onto 
patterns  [thin  bar,  thick  bar,  thin  bar],  etc. 

Hyperlinking  allows  us  to  use  an  alternative  part  of  the  screen  to  actively  show  additional 
information  pertaining  to  the  location  specified  by  a  pointer.  For  example,  dimensions 
D12,  D13,  D14  could  be  mapped  into  an  active  window  such  that  the  relevant  string 
would  be  depicted  whenever  the  mouse  cursor  was  over  a  (real)  X,Y  coordinate  used  as 
part  of  the  depiction  of  some  trip. 

Some  dimensions  can  be  collapsed  into  others.  In  the  example  above,  for  any  given  asset, 
differing  coordinates  in  D15  (sequence  of  segments)  imply  differing  coordinates  in  D18 
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(time),  so  we  can  collapse  D15  onto  D18  without  losing  any  information,  as  indicated  in 
Figure  14.  Collapsing  D15  onto  D18  assumes  we  map  D17  (segment  status)  to  color  or 
some  other  dimension  distinct  from  D18  otherwise  the  association  between  trip  segments 
and  trip  status  may  be  lost.  Likewise,  we  might  be  able  to  collapse  DIO  (sequence  of 
trips)  into  D18  as  well,  assuming  we  map  D12  (trip  description)  to  a  hyperlink  dimension 
or  some  other  dimension  distinct  from  D18. 

Tiling  can  be  useful  when  one  or  more  dimensions  are  finite.  For  example,  the 
dimensions  used  to  draw  an  individual  character  are  finite,  hence  if  the  (finite)  virtual  X 
dimension  for  characters  in  some  sequence  is  mapped  into  the  real  X  dimension,  a 
sequence  of  such  characters  can  be  depicted  by  tiling  that  finite  dimension  into  repetitions 
along  the  X  axis,  using  coordinates  in  the  sequence  dimension  to  select  particular  tiles. 
For  another  example,  the  durations  in  dimension  D18  are  bounded,  and  in  particular  are 
bounded  from  below  by  0,  so  if  we  map  D18  onto  the  real  X  axis  we  can  map  some  other 
virtual  dimension  that  is  finite  (e.g.  D17,  D12,  or  even  D5)  into  the  unused  part  of  the  real 
X  axis.  Sequences  and  tuples  in  general  often  allow  these  two  different  kinds  of  tiling, 
respectively. 

Ignoring  a  dimension  is  useful  when  we  just  don't  care  to  see  some  particular  information, 
or  when  the  dimensional  clutter  is  otherwise  too  great  and  we  need  to  look  at  lower¬ 
dimensional  slices.  In  this  example,  we  might  choose  to  ignore  dimension  D12  (trip 
description)  and  possibly  D7  (asset  name)  if  we  were  just  looking  to  see  if  a  feasible 
schedule  exists.  This  can  be  viewed  as  a  degenerate  kind  of  hyperlinking  to  oblivion. 

For  the  demo  given  in  September  of  1996,  one  result  of  interactively  making  choiees  as 
described  above  was  the  screen  partially  shown  in  Figure  15.  Other  formats,  such  as  a 
swapping  of  the  X  and  Y  axis,  were  possible  but  were  more  crudely  rendered,  since  the 
intent  of  that  demo  was  limited  primarily  to  showing  that  a  traditional  Gantt  chart  could 
be  generated.  In  this  picture,  a  trip  segment  status  has  been  mapped  to  color  using  the 
rules  {loading  ->  blue,  flying  ->  red,  unloading  ->  green},  time  has  been  mapped  on  the  X 
axis,  the  set  of  assets  have  been  arranged  along  the  Y  axis,  and  labels  for  both  the  entire 
schedule  and  each  asset  have  been  oriented  as  normal  horizontal  text.  Some  dimensions 
were  ignored  to  make  the  rendering  compact. 

A  mature  graphics  engine  would  probably  provide  a  more  graceful  facility  than  a  simple 
menu  for  describing  and  assigning  virtual  dimensions  to  actual  (renderable)  dimentsions. 
It  would  also  contain  a  constraint  system  to  ensure  that  user  choices  for  embedding 
dimensions  are  consistent,  to  automatically  make  choices  based  on  constraint 
propagation,  and  to  allow  default  embeddings  based  on  heuristics  and/or  user  profiles, 
etc. 
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iAssi^n.  Dimens  iort|  |Exit 


Figure  15 


Overall,  the  model  we  have  developed  shows  promise  as  an  extremely  flexible  tool  for 
rendering  complex  data.  By  making  rendering  decisions  about  the  various  dimensions  as 
orthogonal  as  the  data  permit,  we  expect  to  be  able  to  encourage  depiction  experiments 
that  otherwise  might  not  occur  to  people,  and  which  would  be  too  expensive  to  explore 
with  traditional  programming  techniques.  That  kind  of  high  level  experimentation 
provides  an  exeellent  medium  for  achieving  optimal  (and  occasionally  breakthrough  or 
paradigm-shifting)  results  in  real  world  applications. 

6.  The  Role  of  Sound 

Sound  is  an  important,  but  under-utilized  and  under-explored  channel  for  software 
understanding.  Note  the  following  key  features  of  sound  for  understanding; 

•  Sound  provides  an  extra  channel  for  providing  information  to  the 
programmer,  which  can  be  used  in  parallel  with  visualization. 

•  It  can  provide  new  ways  of  understanding  programs.  For  example,  sounds 
gives  a  better  sense  of  timing  than  visual  displays. 

With  the  help  of  a  consultant,  Stanley  Jordan,  we  explored  the  possible  uses  of  music  and 
sound  to  aid  in  the  development  and  understanding  of  software. 
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The  following  are  the  areas  where  we  considered  using  sound: 

•  During  Editing,  for  keeping  track  of 

(a)  what  you  are  doing,  and 

(b)  the  state  of  program. 

•  During  Debugging 

•  Understanding  and  managing  the  run-time  behavior  of  the  program,  e.g. 

(a)  tuning  performance,  and 

(b)  monitoring  progress. 

•  User  interface  enhancement 

•  Program/Derivation  Understanding 

As  a  relatively  simple  experiment  we  took  the  output  of  our  scheduling  program  and 
converted  the  trips  into  MIDI  data.  We  used  the  natural  mappings  of  time  in  the  schedule 
to  musical  time,  and  quantity  to  volume.  Other  attributes  such  as  kind  of  cargo  were 
mapped  to  different  instruments  of  pitches.  We  tried  different  assignments  so  as  to 
emphasize  distinctions  between  different  attributes.  Playing  the  schedule  at  an 
accelerated  rate  gave  an  interesting  overview  of  the  schedule.  We  view  this  work  as 
promising,  but  still  quite  experimental. 

As  an  avenue  for  future  research,  we  note  the  parallel  between  transformational  synthesis 
(as  in  KIDS/Specware  derivations)  and  certain  methods  of  music  composition/analysis 
(e.g.  Schenkerian).  A  possible  connection  to  exploration  involves  finding  musical 
refinements  corresponding  to  different  program  refinements.  Given  such  an  approach, 
one  could  derive  a  piece  of  music  in  parallel  to  deriving  a  program.  The  structure  of  the 
music  would  have  certain  correspondences  to  the  program.  By  analogy,  the  music  for  an 
inefficient  program  might  have  excessive  repetition.  Extending  the  analogy  further,  by 
introducing  a  variable  for  a  repeated  expression  might  have  a  musical  correspondence 
such  as  using  only  the  first  few  notes  of  a  long  phrase  instead  of  repeatedly  using  the 
whole  phrase. 

A  general  problem  with  using  automatically  generated  music  is  ensuring  that  it  sounds 
reasonable.  Inherent  in  the  approach  of  the  previous  paragraph  is  the  necessity  of 
formalizing  musical  knowledge  in  a  way  comparable  to  our  formalization  of 
programming  knowledge.  This  musical  model  would  have  to  be  rich  enough  to  ensure 
results  that  meet  standards  of  musicality.  One  possibility  is  to  create  models  beginning 
with  pre-composed  pieces  (by  a  musician),  which  are  then  parameterized  for  use  in 
derivations. 

In  brief,  we  believe  that  sound  will  play  an  important  role  in  program  understanding  in 
the  future,  as  the  complexity  of  software  systems  being  built  increases  each  year.  Our 
initial  findings  in  this  area  indicate  that  graphics  are  well-suited  for  uncovering  static 
structure,  whereas  sound  may  help  us  uncover  dynamic  structure  or  timing. 
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7.  Summary 

This  research  explored  various  ways  of  formally  visualizing  software  systems.  We 
explored  relationships  between  views,  data,  and  renderings  in  a  formal  setting  where 
visualizations  were  created  by  mapping  data  onto  abstract  views  that  were  refined  into 
renderable  entities.  We  explored  the  feasibility  of  our  approach  by  developing  both  a 
formal  specification  and  an  implementation  of  a  software  system  for  visualizing 
scheduling  information.  We  also  briefly  explored  the  role  of  sound  as  a  visualization  aid, 
and  found  that  although  more  work  remains  to  be  done,  sound  can  be  effectively  used  to 
analyze  structure.  Our  feasibility  demonstration  conducted  in  September  1996  proved  we 
could  visualize  systems  using  formal  techniques  and  that  such  visualizations  could  be  co¬ 
derived  with  system  software.  However,  much  work  remains.  For  example: 

•  We  feel  that  better  constraint-solving  technology  -  one  handling  more  complex  and 
aggregate  constraints  -  will  greatly  aid  the  system,  and  furthermore,  such  technology 
is  likely  to  be  built  within  the  next  few  years  as  the  importance  of  constraint-based 
reasoning  is  being  realized  in  the  larger  community. 

•  A  better  characterization  of  the  constraints  associated  with  adding  and  using  real 
(renderable)  dimensions  is  needed.  For  example,  under  what  circumstances  can  a 
dimension  be  collapsed  onto  another?  How  can  these  constraints  be  formalized  and 
used  in  the  VIZO  system? 

•  How  can  we  better  support  the  task  of  assigning  virtual  dimensions  to  real 
dimensions?  What  role  should  heuristics  play  and  how  can  they  be  formalized  for  use 
within  VIZO? 

•  Finally,  tlie  role  of  sound  in  analyzing  structure  needs  to  be  better  understood. 

In  brief,  we  feel  that  we  have  demonstrated  the  validity  of  our  premise,  that  visualizations 
can  be  co-derived  with  software  and  used  to  aid  system  understanding. 
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Appendix  A.  Visualization  in  the  Specware  Framework 


A.l.  Overview 


This  appendix  describes  an  implementation  of  visualization  refinement  in  Specware  as 
part  of  the  VIZO  prototype.  This  appendix  is  organized  as  follows: 

•  Section  A.2  contains  a  worked  example; 

•  Section  A.3  describes  diagram  interpretation; 

•  Section  A.4  describes  multiple  representations;  and 

•  Section  A.5  contains  the  Specware  specifications  referenced  in  the  preceding  sections. 

A.2.  Worked  Example 

This  section  describes  a  key  part  of  the  VIZO  prototype:  a  mechanism  for  hooking  the 
visualization  domain  into  the  refinement  process  of  Specware.  We  explored  this 
mechanism  by  creating  and  manipulating  specifications  for  graphical  user  interfaces 
(GUIs). 

A.2.1.  GUI  Template 

The  specification  gui  Template  (given  in  Section  A.5)  is  a  template  for  constructing 
Specware  interpretations  which  map  abstract  views  to  concrete  visual  representations. 
There  may  be  more  than  one  concrete  object  for  each  abstract  object,  and  each  concrete 
object  may  use  a  different  representation  scheme.  Intervening  between  the  concrete  and 
abstract  objects  are  representation  objects.  This  very  general  scheme  allows  us  to  not 
only  manipulate  screen  objects  by  modifying  the  underlying  data  or  entity  being 
represented,  but  it  also  allows  us  to  manipulate  the  data  via,  say,  mouse  operations  on  the 
screen  objects. 

Figures  A.l  through  A.3  show  three  different  aspects  of  the  GIU  Template.  Figure  A.l 
shows  GUI  Template  at  an  overview  level.  Figure  A.2  shows  the  internal  structure  in 
more  detail,  and  Figure  A.3  illustrates  the  relationship  between  the  pieces  of  the  internal 
structure  and  how  they  enable  flexible  visualizations.  Figure  A.4  shows  how  the  GUI 
Template  specification  is  an  interpretation  scheme  called  Triv-to-Dobj,  whose  pieces  can 
later  be  refined  to  form  interpretations  for  specific  visualizations.  (See  Section  A.3. 2.) 
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GUI  Template:  Abstract  as  Concrete 


Abstract  Thing  1  (relation,  data,  etc.) 

<ball,  bat> 


(screen  objects) 


Figure  A.l 


Abstract  Thing 


Figure  A.2 

In  Figure  A.2,  rep  1,  rep  2,  rep  3,  and  rep  4  all  represent  the  same  abstract  entity. 
Similarly,  cone  1,  cone  2,  cone  3,  and  cone  4  are  concrete  (displayable)  representations  of 
the  abstract  entity.  Note  that  cone  5  is  a  concrete  representation  that  is  not  a  valid 
representation  of  Abstract  Thing. 
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Figure  A.3 

Consider  the  example  depicted  in  Figure  A.3  where  two  pairs  of  symbols  are  represented 
on  the  screen  as  two  pairs  of  adjacent  boxes  with  text  labels.  “Paimess”  is  being 
represented  using  adjacency.  It  happens  that  “bar”  and  “yin”  have  been  placed  adjacent  to 
each  other,  however,  the  pair  <bar,  yin>  is  not  in  the  set  of  pairs  being  represented.  Thus, 
below  we  see  that  the  three  adjacent  pairs  of  labels  are  in  the  concrete  sort,  but  only  two 
of  the  three  are  in  the  rep  sort.  Rep  is  a  subsort  of  cone.  Notice  that  in  this  example, 
unlike  the  diagram  above,  each  abstract  element  has  only  one  rep. 


Abs  <foo,  bar>,  <yin,  yang> 


Rep 


Cone 


ED 

bar 

yin 

yang 

IfoJ 

bar 

1 

yang 

foo 

Ej 

[3 

yang 

Figure  A.4 


A.2.2.  Display  Objects 

Figure  A.5  shows  the  root  of  a  hierarchy  of  display  objects,  and  includes  a  legend  for 
Figures  A.5-A.8.  Notice  that  the  named  objects  are  names  of  specifications  which  appear 
in  Section  A.5.  Figure  A.6  is  an  annotated  version  of  a  Speeware  diagram  for  the 
interpretation  Pair-to-AdjXPair,  in  which  the  GUI  Template  described  in  Section  A.2.1  is 
instantiated.  As  it's  name  suggests,  Pair-to-AdjXPair  refines  an  abstract  pair  of  items  into 
a  pair  of  visual  representations  (as  regions)  of  those  items,  with  the  added  constraint  that 
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their  regions  must  be  horizontally  adjacent.  Figure  A.7  shows  a  three-dimensional 
Specware  diagram  of  an  interpretation  (including  its  component  parts)  of  a  particular  pair 
into  a  pair  of  adjacent  visual  regions.  Notice  that  the  diagram  in  Figure  A.6  of  Pair-to- 
AdjXPair  is  actually  a  subdiagram  of  this  full  diagram  (it  is  the  entire  backmost  plane  of 
the  3D  shape).  This  illustrates  one  manner  in  which  refinements  themselves  can  be 
composed  and  refined  in  Specware.  Finally,  Figure  A.  8  shows  the  same  full  example,  but 
abstracted  slightly  to  show  how  it  is  constructed  incrementally,  starting  with  the  GUI 
Template  on  the  left  and  ending  with  the  final  refinement  on  the  right. 

In  order  to  better  illustrate  the  visual  language  of  Specware,  we  will  explain  in  detail  the 
full  diagram  in  Figure  A.7.  The  diagram  is  structured  as  a  three  dimensional  lattice  with 
the  lattice  points  being  specifications  and  the  arrows  being  morphisms  between  the 
specifications.  Each  specification  has  a  textual  identifier  as  well  as  a  graphical  depiction. 
The  morphisms  do  not  show  their  full  structure  here,  however  notice  that  some 
morphisms  are  annotated  with  a  small  "d"  indicating  that  they  are  definitional  extension 
morphisms.  The  lattice  is  basically  a  three  dimensional  box:  three  specs  wide,  three  specs 
tall,  and  two  specs  deep.  There  is  an  additional  buttress  plane  which  juts  out  from  the 
middle  front  vertical  line  towards  the  viewer. 

Each  plane  in  the  structure  highlights  a  semantically  significant  relation  among  the  specs 
which  participate  in  that  plane.  For  instance,  the  topmost  plane  consists  of  abstract  data 
type  specs,  while  the  bottom-most  plane  consists  of  visual  element  specs.  The 
intervening  plane  contains  the  mediator  specs  which  complete  the  interpretations  (and 
interpretation  schemes)  between  the  abstract  and  the  visual  specs.  We  have  used  a 
depiction  of  a  computer  screen  for  each  spec  at  this  level,  indicating  that  these  are  specs 
which  can  be  used  directly  to  create  automated  visualizations.  The  specs  in  the  left  and 
right  most  vertical  planes  serve  as  component  specs  to  the  specs  in  the  middle  vertical 
plane.  For  example,  The  spec  labeled  "Person"  and  the  spec  labeled  "Name"  are 
components  that  are  imported  to  create  the  spec  labeled  "Pair(Person,  Name)". 

Working  from  back  to  front  we  see  an  instantiation  process.  The  back-most  plane  is  most 
generic  (e.g.  it  contains  a  spec,  "Pair",  which  describes  all  possible  pairs  of  elements  in 
the  universe).  The  front  plane  of  the  box  instantiates  the  specs  in  the  back  plane  and  thus 
restricts  the  possible  models  for  each  spec  (e.g.  all  pairs  of  persons  and  names).  The 
buttress  instantiates  the  specs  further  by  choosing  one  particular  instance  (e.g.  the  pair 
whose  first  element  is  ss#l 23-45-6789  and  whose  second  element  is  John  Doe). 

In  choosing  representations  for  abstract  concepts,  especially  when  several  similar 
concepts  are  simultaneously  being  displayed,  we  have  found  it  useful  to  take  a  "minimal 
model"  approach.  The  idea  is  to  represent  the  concept  as  abstractly  as  possible  (so  that  it 
covers  all  intended  models)  while  still  conveying  the  concept  unambiguously.  Also 
important  is  to  not  introduce  spurious  relationships. 
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A.  3.  Further  Refinement 


After  our  initial  model  of  visualization  in  Specware,  we  began  to  refine  it  based  on  our 
experience  and  improved  theoretical  understanding. 

A.  3 . 1 .  Multiple  Representations 

We  begin  with  a  theory  of  multiple  representations  (see  Figure  A.9).  A  concrete 
representation  of  an  abstract  object  A  is  an  object  C  with  an  abstraction  map  abs  :  C  ->  A 
and  a  representation  map  rep  :  A  ->  C.  We  require  that  abs  °  rep  =  id,  so  that  rep  is 
injective  and  abs  is  surjective.  Thus,  a  representation  may  have  more  information  than 
the  abstract  object  that  it  represents.  For  example,  a  representation  of  a  person’s  name 
may  have  a  position  on  the  screen  and  a  bitmap  displaying  the  text  in  some  font. 

However,  since  rep  is  injective,  the  concrete  object  always  contains  the  full  content  of  the 
abstract  object. 

Given  two  concrete  representations  (Ci,  rep^,  abs{)  and  (C2,  rep2,  absi)  of  an  abstract 
object  A,  the  images  of  A  in  Cj  and  C2  (via  repi  and  rep2)  are  isomorphic  via/j2  =  rep2  ° 
absi  and /21  =  repi  °  abs2.  That  is, 

fix  °fi2  °  repi  =  repi 
fn  °  fix  °  rep2  =  rep2 

The  entire  representations  are  not  isomorphic,  just  the  images  of  the  abstract  object  within 
the  representations. 

This  theory  appears  to  have  two  problems.  First,  it  does  not  appear  to  account  for 
representations  that  show  only  part  of  an  object,  since  the  representation  map  must  be 
injective.  For  example,  suppose  we  want  to  show  only  the  parity  of  an  integer  (whether  it 
is  even  or  odd).  Second,  the  primacy  of  the  abstract  object  seems  to  contradict  the  idea 
that  all  representations  are  on  equal  footing. 

By  viewing  the  same  theory  in  a  slightly  different  way,  we  can  remove  both  difficulties. 

In  place  of  an  abstract  object,  we  choose  view,  some  aspect  of  the  object  we  would  like  to 
present.  For  example,  a  view  for  parity  would  be  {0,1 }.  In  the  above  discussion,  the 
view  replaces  the  abstract  object,  and  the  abstract  object  becomes  just  another  concrete 
object.  This  method  also  allows  multiple  views  of  the  same  object  (see  Figure  A.9). 

The  theory  of  multiple  representations,  as  presented  here,  is  formally  identical  to  the 
theory  of  fiber  bundles,  which  is  dual  to  patching  theory.  In  patching  theory,  we  are 
concerned  with  compatible  covers  of  a  large  object,  while  in  bundle  theory  we  are 
concerned  with  compatible  representations  (see  Figure  A.  10). 


27 


Finally,  we  see  that  this  theory  also  applies  to  classes  of  objects  with  internal  structure, 
such  as  lists.  In  this  case,  the  abstraction  and  representation  functions  are  list 
homomorphisms: 

(rep  (nill) )  =  (nil2) 

(rep  (consl  a  1) )  =  (cons2  a  (rep  1) ) 

A.3.2.  Specifications 

To  build  these  ideas  into  a  specification  for  pairs  of  people  and  names,  we  need  several 
components: 

•  A  theory  of  pair  homomorphisms 

•  A  theory  of  multiple  representations 

•  A  theory  of  visualizations  of  pairs 

These  theories  are  shown  in  Section  A.5.2.  The  theories  of  pair  homomorphisms  and 
multiple  representations  are  straightforward.  We  then  glue  three  copies  of  the 
representation  theory  to  two  copies  of  the  pair  homomorphism  theory  to  capture  the 
notion  that  both  the  abstraction  and  representation  maps  are  pair  homomorphisms. 

To  visualize  pairs,  we  need  the  idea  of  a  pair  as  a  displayable  object,  whose  components 
are  displayable  objects,  and  whose  components  are  adjacent.  We  build  this  theory  from 
components  using  a  ladder  construction.  We  start  with  OBJECT,  the  basic  theory  of 
objects.  We  specialize  OBJECT  to  make  PAIR  and  DISPLAY-OBJECT,  then  use  a 
colimit  to  generate  DISPLAY-PAIR.  In  this  way,  we  combine  two  independent  theories 
automatically. 
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Lobj  =  Dobj  +  Label 


-  extent  of  Dobj 

-  Dobj  may  contain  other  stuff 

-  extent  of  label 

-  label  content 

-  z-adj 


Figure  A.5:  Display  Objects 
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After  specializing  PAIR  to  pairs  of  display  objects  and  further  to  pairs  of  adjacent  display 
objects,  we  use  colimits  twice  more  generate  displayable  pairs  of  adjacent  display 
objects.  Colimits  solve  the  multiple  inheritance  problem  by  allowing  us  to  control 
sharing.  Thus,  we  can  specify  new  concepts  where  they  are  fundamental  and  propagate 
them  to  where  they  are  needed.  For  example,  “displayability”  is  a  property  of  objects,  not 
of  pairs,  but  we  can  propagate  it  to  pairs  using  a  colimit. 


Pair 


Result:  Representation  of  Pair  as  AdjXPair  is  an  instance  of  GUI  template, 
and  can  therefore  be  reused  in  further  construction. 

Figure  A.  6:  Pair  to  AdjXPair 
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A. 5.  Specware  Specifications 

A.5.1.  GUI  Template 

%%  Mode:  RE;  Package:  SPEC;  Base:  10;  Syntax:  Refine 

!!  in-package {" SPEC" ) 

! !  in-grammar { ' SLANG : : SPEC-GRAMMAR) 


Q,Q,Q.Q,Q.Q,Q,Q,Q,Q,Q, 

'6 
Q,  Q, 


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
%%  Auxiliary  files: 

relations . re,  tuples. re 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 


1%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 


%%  Abstract  description  of  regions 

%%  The  model  to  keep  in  mind  is  a  2.5-D  display  (i.e.,  2-D  display 
%%  with  layering) 


spec  REGION  is 
sort  Region 

%%  adjacency  in  different  directions 

op  adj-x?  :  Region,  Region  ->  Boolean 

op  adj-y?  :  Region,  Region  ->  Boolean 

op  adj-z?  :  Region,  Region  ->  Boolean 

%%  (contains  x  y)  is  to  be  read  as  x  contains  y 

op  contains  :  Region,  Region  ->  Boolean 

end- spec 


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

%%  Abstract  display  objects  encompass  anything  that  can  be 
%%  displayed.  In  an  OOP  system  this  would  be  the  root  of  a  hierarchy 
%%  of  displayable  objects. 

%%  For  now,  the  only  thing  we  assume  about  abstract  display  objects  is 
%%  that  each  such  object  has  an  underlying  region  (its  extent) .  This 
%%  theory  could  be  augmented  with  other  generic  attributes  (e.g., 

%%  position)  and  generic  methods  (e.g.,  mouse-handlers). 

spec  DISPLAY-OBJECT  is 
import  REGION 


sort  D-Object 

op  extent  :  D-Object  ->  Region 
end- spec 


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 


%%  Labels  are  some  display  objects  which  some  "content".  For  now,  this 
%%  content  is  either  a  picture  or  a  piece  of  text  (we  don't  specify 
%%  what  pictures  and  text  are)  . 

spec  TEXT  is  sort  Text  end-spec 
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spec  PICTURE  is  sort  Picture  end-spec 
spec  LABEL  is 

import  translate  DISPLAY-OBJECT  by  {D-Object  ->  Label}, 

TEXT,  PICTURE 

op  content  :  Label  ->  (Picture  +  Text) 
end- spec 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

%%  Any  display  object  can  be  labelled  by  attaching  a  label  to 
%%  it.  "Attaching"  here  means  that  an  object  and  its  label  are 
%%  adjacent  in  the  z-direction. 

spec  LABELLED-DISPLAY-OBJECT  is 
import 
translate 

colimit  of  diagram 

nodes  DISPLAY-OBJECT,  REGION,  LABEL 
arcs  REGION  ->  DISPLAY-OBJECT  :  {), 

REGION  ->  LABEL  :  {} 
end-diagram 

by  {D-Object  ->  LD-Object] 

op  Ibl  :  LD-Object  ->  Label 

axiom  label-is-adj -z  is 

(adj-z?  (extent  Id-obj )  (extent  (Ibl  Id-obj ) ) ) 

end-spec 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
%%  Pair  of  objects  which  are  adjacent  in  the  x-direction. 


%% 

h - 

%% 

+ 

+ 

+ 

%% 

1  L  1  R  i 

%% 

+ 

+ 

+ 

%%  H 

f-T - 

spec  ADJ-X-PAIR  is 
import 
translate 

colimit  of  diagram 

nodes  pair  ;  DISPLAY-OBJECT, 
left  :  DISPLAY-OBJECT, 
right:  DISPLAY-OBJECT, 

REGION 

arcs  REGION  ->  pair  :  import-morphism, 
REGION  ->  left  :  import-morphism, 
REGION  ->  right:  import-morphism 
end-diagram 

by  {pair .D-Object  ->  Adj-x-Pair, 

left .D-Object  ->  Left-D-Object, 
right .D-Object  ->  Right-D-Object} 

op  pair-left  :  Adj-x-pair  ->  Left-D-Object 
op  pair-right  :  Adj-x-pair  ->  Right -D-Object 
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%%  left  and  right  regions  are  contained  in  the  overall  region 

axiom  (contains  (extent  p)  (extent  (pair-left  p) ) ) 
axiom  (contains  (extent  p)  (extent  (pair-right  p) ) ) 

%%  left  and  right  regions  are  adjacent  in  the  x-direction 

axiom  (adj-x?  (extent  (pair-left  p) )  (extent  (pair-right  p) ) ) 

end-spec 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%^^%^^^^^^ 
%%  Template  for  displaying  something  on  the  screen 

%%  abstract-sort  a  a 

/  \  /  \  equiv-rep? 

%%  rep-subsort  rrrrrrrr  rep’ 

%%  I  I  I  I  I  I  I  I 

%%  concrete-sort  cccccccccccccc 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%^^%^%^^^^ 

spec  GUI -TEMPLATE  is 

sorts  Abstract-Sort,  Concrete-Sort 

sort-axiom  Abstract-Sort  =  Concrete-Sort  |  rep?  /  equiv-rep? 

op  rep  :  Abstract-Sort,  Concrete-Sort  ->  Boolean 
op  abs  :  Concrete-Sort  |  rep?  ->  Abstract-Sort 

op  rep?  :  Concrete-Sort  ->  Boolean 

op  equiv-rep?  :  Concrete-Sort  |  rep?,  Concrete-Sort  |  rep?  ->  Boolean 

%%  rep?  picks  outs  the  subsort  of  representatives 

definition  of  rep?  is 

axiom  (iff  (rep?  r)  (ex  (a)  (rep  a  r) ) ) 
end-def inition 

%%  any  two  representatives  of  an  abstract  thing  are  equivalent 

definition  of  equiv-rep?  is 
axiom  (iff 

(equiv-rep?  rl  r2) 

(ex  (a)  (and  (rep  a  ((relax  rep?)  rl) ) 

(rep  a  ((relax  rep?)  r2) ) ) ) ) 

end-def inition 

%%  abs  is  the  abstraction  function  for  the  quotient  sort  Abstract-Sort. 

%%  Hence  it  is  the  "inverse"  of  rep, 

definition  of  abs  is 

axiom  (equal  (abs  r)  ((quotient  equiv-rep?)  r) ) 
end-definition 

theorem  abs-is-rep-inverse  is 

(iff  (rep  a  ((relax  rep?)  r) )  (equal  a  (abs  r) ) ) 

end- spec 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

%%  GUI-TEMPLATE  in  which  the  concrete  sort  is  a  display  object 
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spec  TRIV-as-D-OBJECT  is 
colimit  of  diagram 

nodes  TRIV,  DISPLAY-OBJECT,  GUI-TEMPLATE 
arcs  TRIV  ->  DISPLAY-OBJECT  :  {E  ->  D-Object}, 

TRIV  ->  GUI-TEMPLATE  :  {E  ->  Concrete-Sort} 
end-diagram 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

ip-scheme  Triv-to-D-Object  :  TRIV  =>  DISPLAY-OBJECT  is 
mediator  TRIV-as-D-OBJECT 
dom-to-med  {E  ->  Abstract-Sort) 
cod-to-med  cocone-morphism  from  DISPLAY-OBJECT 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

%%  Given  that  there  are  schemes  for  representing  the  left  and  right 
%%  components  of  a  pair,  the  representation  of  the  pair  itself  imposes 
%%  the  additional  constraint  that  the  chosen  representatives  for  the 
%%  components  be  adjacent  in  the  x-direction. 

diagram  PAIR-as-ADJ-X-PAIR--IMPORT-DIAGRAM  is 
nodes  body  :  ADJ-X-PAIR, 

left- formal  :  DISPLAY-OBJECT, 
right-formal  :  DISPLAY-OBJECT, 
shared- formal ;  REGION, 
left-actual  :  TRIV-as-D-OBJECT, 
right-actual  :  TRIV-as-D-OBJECT, 
shared-actual:  REGION, 

TRIV, 

gui- template- for-pair  :  GUI-TEMPLATE 
arcs  left-formal  ->  body  :  {D-Object  ->  Left-D-Object, 

extent  ->  left . extent) , 

left-formal  ->  left-actual  :  cocone-morphism  from  DISPLAY-OBJECT, 

right-formal  ->  body  :  {D-Object  ->  Right-D-Object, 

extent  ->  right . extent) , 

right-formal  ->  right-actual  :  cocone-morphism  from  DISPLAY-OBJECT, 

shared-formal  ->  left-formal  :  import-morphism, 

shared-formal  ->  right-formal  :  import-morphism, 

shared-actual  ->  left-actual  :  {}, 

shared-actual  ->  right-actual  :  {), 

shared-formal  ->  shared-actual:  identity-morphism, 

% 

TRIV  ->  body  :  {E  ->  Adj-x-pair), 

TRIV  ->  gui-template-for-pair  :  {E  ->  Concrete-Sort) 
end-diagram 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

spec  PAIR-as-ADJ-X-PAIR  is 
import 
translate 

colimit  of  PAIR-as-ADJ-X-PAIR — IMPORT-DIAGRAM 
by  {left-actual .Abstract-Sort  ->  Left-Abstract-Sort, 
right-actual .Abstract-Sort  ->  Right-Abstract-Sort, 
gui-template-for-pair .Abstract-Sort  ->  Adj -x-Pair-Q) 

definition  of  gui-template-f or-pair . rep  is 
axiom  (iff  (rep  abstract-pair  region-pair) 

(and  (rep  (pi-1  abstract-pair)  (pair-left  region-pair) ) 
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(rep  (pi-2  abstract-pair)  (pair-right  region-pair) ) ) ) 

end-definition 

op  make-pair  :  Left-Abstract-Sort,  Right-Abstract-Sort  ->  Adj-x-pair-Q 
op  pi-1  :  Adj-x-pair-Q  ->  Left-Abstract-Sort 
op  pi-2  :  Adj-x-pair-Q  ->  Right-Abstract-Sort 

%%  non-constructive  definition 
definition  of  make-pair  is 
axiom  (iff 

(equal  (make-pair  1  r)  p) 


(and  (equal 

(pi-1 

P)  1) 

(equal 

(pi-2 

P)  r))) 

end- de  f ini t i on 

%%  L 

P 

R 

abstract- sort 

%%  / 

\ 

/|\ 

/1\ 

equiv-rep? 

%%  / 

\  pi-1 

/  1  \ 

pi-2 

/  1  \ 

%%  — L —  < - 

--P-- 

- > 

— R-- 

rep- subsort 

%% 

left 

1 

right 

1 

rep? 

%%  --L-- 

--P-- 

— R — 

concrete- sort 

definition  of  pi-1 

is 

axiom  (iff 

(equal  (pi-1  ( (quotient  equiv-rep?)  p) )  ( (quotient  equiv-rep?)  1) ) 

(equal  (pair-left  ((relax  rep?)  p) )  ((relax  rep?)  1))) 
end-def inition 

definition  of  pi-2  is 
axiom  (iff 

(equal  (pi-2  ((quotient  equiv-rep?)  p) )  ((quotient  equiv-rep?)  r) ) 
(equal  (pair-right  ( (relax  rep?)  p) )  ( (relax  rep?)  r) ) ) 

end-definition 

end-spec 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

interpretation 

PAIR-to-ADJ-X-PAIR  :  PAIR  =>  ADJ-X-PAIR  is 
mediator  PAIR-as -ADJ-X-PAIR 

dom-to-med  {L  ->  Left-Abstract-Sort, 

R  ->  Right-Abstract-Sort, 

Pair  ->  Adj-x-pair-Q, 

make-pair  ->  make-pair, 

pi-1  ->  pi-1, 

pi-2  ->  pi-2} 

cod-to-med  {pair. extent  ->  body. pair .extent, 
left. extent  ->  body . left . extent, 
right. extent  ->  body. right. extent) 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

%%  spec  with  example  pair 

spec  PERSON  is 
sort  Person 
const  PI  :  Person 
end-spec 
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spec  NAME  is 
sort  Name 
const  N1  :  Name 
end-spec 

%%  Observe  the  use  of  the  empty  specification  to  take  the  coproduct  of 
%%  the  actuals,  PERSON  and  NAME.  This  is  necessary  because  both  these 
%%  specs  will  be  refined  into  the  same  spec  SAMPLE-LABELS. 

%%  The  refinement  of  a  colimit  diagram  produces  a  target  spec  defined 
%%  as  the  colimit  of  a  diagram  of  the  same  shape.  Had  we  not  used  the 
%%  empty  spec,  the  refinement  would  have  created  two  copies  of 
%%  SAMPLE-LABELS. 

spec  EMPTY  is  end- spec 

spec  SAMPLE-PAIR  is 
import 
translate 

colimit  of  diagram 

nodes  TRIVl:  TRIV,  TRIV2 :  TRIV,  PAIR,  EMPTY, 


PERSON,  NAME 


arcs  TRIVl 

->  PAIR 

:  {E 

-> 

L), 

TRIVl 

->  PERSON 

:  {E 

-> 

Person} , 

TRIV2 

->  PAIR 

:  {E 

-> 

R}, 

TRIV2 

->  NAME 

:  {E 

-> 

Name } , 

EMPTY  -> 

PERSON  : 

{}, 

EMPTY  ->  NAME  :  {} 
end-diagram 

by  {L  ->  Person,  R  ->  Name} 

const  sample-pair  :  Pair 

definition  of  sample-pair  is 

axiom  (equal  sample-pair  (make-pair  Pi  Nl) ) 
end- definition 

end-spec 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

%%  Sample  refinements  for  components  of  sample  pair 

spec  SAMPLE-LABELS  is 

import  LABELLED-DISPLAY-OBJECT 
%%  picture  corresponding  to  sample  person 
const  Pl-pic  :  Picture 
%%  text  corresponding  to  sample  name 
const  Nl-txt  :  Text 
end- spec 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

spec  PERSON-as-SAMPLE-LABELS  is 
import 

colimit  of  diagram 

nodes  TRIV,  SAMPLE-LABELS,  GUI-TEMPLATE 
arcs  TRIV  ->  SAMPLE-LABELS  ;  {E  ->  LD-Object}, 

TRIV  ->  GUI-TEMPLATE  :  {E  ->  Concrete-Sort) 
end-diagram 

%%  objects  which  represent  persons  are  labelled  with  pictures 
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axiom  (implies  (rep?  x) 

(ex  (pic)  (equal  (content  ( Ibl  x) )  ((embed  1)  pic)))) 

%%  two  person-reps  are  equal  iff  they  are  labelled  by  the  same  picture 

definition  of  equiv-rep?  is 
axiom  (iff 

(equiv-rep?  person-repl  person-rep2) 

(equal  (content  (Ibl  ((relax  rep?)  person-repl))) 

(content  (Ibl  ((relax  rep?)  person-rep2 ) ) ) ) ) 

end-def inition 

const  Pl-abs  :  Abstract-Sort 

%%  any  representation  of  sample  person  should  be  labelled  by  sample  picture 

axiom  (iff 

(rep  Pl-abs  Pl-rep) 

(ex  (Pl-mid) 

(and  (equal  Pl-abs  (abs  Pl-mid)) 

(equal  (content  (Ibl  ((relax  rep?)  Pl-mid))) 

((embed  1)  Pl-pic) ) ) ) ) 


end- spec 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

ip-scheme  PERSON-to-SAMPLE-LABELS  :  PERSON  =>  SAMPLE-LABELS  is 
mediator  PERSON-as-SAMPLE-LABELS 
dom-to-med  {Person  ->  Abstract-Sort, 

PI  ->  Pl-abs} 

cod-to-med  (LABEL . extent  ->  SAMPLE- LABELS. LABEL. extent, 

DISPLAY-OBJECT. extent  ->  SAMPLE-LABELS. DISPLAY- OBJECT. extent) 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

spec  NAME-as-SAMPLE-LABELS  is 
import 

colimit  of  diagram 

nodes  TRIV,  SAMPLE-LABELS,  GUI-TEMPLATE 
arcs  TRIV  ->  SAMPLE-LABELS  :  (E  ->  LD-Object) , 

TRIV  ->  GUI-TEMPLATE  :  (E  ->  Concrete-Sort) 
end- diagram 

%%  objects  which  represent  names  are  labelled  with  text 
axiom  (implies  (rep?  x) 

(ex  (txt)  (equal  (content  (Ibl  x) )  ((embed  2)  txt) ) ) ) 

%%  two  name-reps  are  equal  iff  they  are  labelled  by  the  same  text 

definition  of  equiv-rep?  is 
axiom  (iff 

(equiv-rep?  name-repl  name-rep2) 

(equal  (content  (Ibl  ( (relax  rep?)  name-repl))) 

(content  (Ibl  ((relax  rep?)  name-rep2 ) ) ) ) ) 

end-def inition 

const  Nl-abs  :  Abstract-Sort 
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%%  any  representation  of  sample  name  should  be  labelled  by  sample  text 

axiom  (iff 

(rep  Nl-abs  Nl-rep) 

(ex  (Nl-mid) 

(and  (equal  Nl-abs  (abs  Nl-mid)) 

(equal  (content  ( Ibl  ((relax  rep?)  Nl-mid))) 

((embed  2)  Nl-txt) ) ) ) ) 


end- spec 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

ip-scheme  NAME-to-SAMPLE-LABELS  :  NAME  =>  SAMPLE-LABELS  is 
mediator  NAME-as-SAMPLE-LABELS 
dom-to-med  {Name  ->  Abstract-Sort, 

N1  ->  Nl-abs} 

cod-to-med  {LABEL . extent  ->  SAMPLE- LABELS. LABEL. extent, 

DISPLAY-OBJECT. extent  ->  SAMPLE-LABELS. DISPLAY- OBJECT. extent} 


ip -scheme 

EMPTY-to-LABELLED-DISPLAY-OBJECT  :  EMPTY  =>  LABELLED-DISPLAY-OBJECT 
is 

mediator  LABELLED-DISPLAY-OBJECT 
dom-to-med  {} 

cod-to-med  identity-morphism 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 


A.5.2,  Display  Pair 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

%%  A  concrete  representation  of  an  abstract  object. 
%%  ABS  is  surjective,  REP  is  injective. 

spec  REP  is 

sorts  Abstract,  Concrete 

op  rep  :  Abstract  ->  Concrete 
op  abs  :  Concrete  ->  Abstract 

axiom  (equal  (abs  (rep  a))  a) 

op  abs?  :  Abstract,  Concrete  ->  Boolean 
op  rep?  :  Concrete,  Abstract  ->  Boolean 

definition  of  abs?  is 

axiom  (iff  (abs?  a  c)  (equal  a  (abs  c) ) ) 
end-def inition 

definition  of  rep?  is 

axiom  (equal  (rep?  c  a)  (abs?  a  c) ) 
end-def inition 

end- spec 
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%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

%%  Pair  Homomorphisms 

%%  SOURCE. Left  <-  SOURCE. Pair  ->  SOURCE. Right 

%%  I  I  I 

%%  V  V  V 

%%  DEST.Left  <-  DEST.Pair  ->  BEST. Right 

spec  PAIR-HOMOMORPHISM  is 

import  SOURCE  :  PAIR,  BEST  :  PAIR 

op  left-map  :  SOURCE. Left  ->  BEST. Left 
op  right-map  :  SOURCE. Right  ->  BEST. Right 
op  pair-map  :  SOURCE. Pair  ->  BEST. Pair 

axiom  (equal  (left-map  ( SOURCE. left  p) )  (BEST. left  (pair-map  p) ) ) 
axiom  (equal  (right-map  ( SOURCE . right  p) )  (BEST. right  (pair-map  p) ) ) 
end- spec 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

%%  The  above  diagram,  with  both  REP  and  ABS  vertically. 

spec  REP- PAIR  is 

translate  colimit  of  diagram 
nodes 

PAIR-AC  :  REP, 

LEFT-AC  :  REP, 

RIGHT-AC  :  REP, 

REP-HOM  :  PAIR-HOMOMORPHISM, 

ABS-HOM  :  PAIR-HOMOMORPHISM, 

PAIR-REP  ;  ARROW,  PAIR-ABS  :  ARROW, 

LEFT-REP  :  ARROW,  LEFT-ABS  :  ARROW, 

RIGHT-REP  ;  ARROW,  RIGHT- ABS  :  ARROW 

arcs 

PAIR-REP  ->  PAIR-AC  :  {  f  ->  rep  }, 

PAIR-REP  ->  REP-HOM  :  {  f  ->  pair-map  }, 

PAIR-ABS  ->  PAIR-AC  :  {  f  ->  abs  }  , 

PAIR-ABS  ->  ABS-HOM  :  {  f  ->  pair-map  ) , 

LEFT-REP  ->  LEFT-AC  :  {  f  ->  rep  }, 

LEFT-REP  ->  REP-HOM  :  {  f  ->  left-map  } , 

LEFT-ABS  ->  LEFT-AC  :  {  f  ->  abs  } , 

LEFT-ABS  ->  ABS-HOM  :  {  f  ->  left-map  ), 

RIGHT-REP  ->  RIGHT-AC  :  {  f  ->  rep  }, 

RIGHT-REP  ->  REP-HOM  :  {  f  ->  right-map  } , 

RIGHT-ABS  ->  RIGHT-AC  :  {  f  ->  abs  ), 

RIGHT-ABS  ->  ABS-HOM  :  {  f  ->  right-map  } 

end-diagram  by 

{  PAIR- AC. Abstract  ->  Pair-Abstract, 

PAIR-AC. Concrete  ->  Pair-Concrete, 

LEFT-AC. Abstract  ->  Left-Abstract, 
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LEFT-AC. Concrete  ->  Left-Concrete, 
RIGHT-AC .Abstract  ->  Right-Abstract, 
RIGHT- AC . Concrete  ->  Right-Concrete  } 


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 


's%  A  ladder,  ending  in  displayable  pairs  of  adjacent  display  objects, 


%% 

%% 

%% 

%% 

%% 

%% 

%% 

%% 

%% 

%% 


OBJECT  ->  DISPLAY-OBJECT 

I  I 

V  V 

PAIR  ->  DISPLAY-PAIR 

I  I 

V  V 
PAIR-OF-DOS  ->  DISPLAY-PAIR-OF-DOS 

I  I 

V  V 
PAIR-OF-ADJ-DOS  ->  DISPLAY-PAIR-OF-ADJ-DOS 


spec  PAIR-OF-DOS  is 

translate  colimit  of  diagram 
nodes 

PAIR,  REGION, 

LEFT  :  DISPLAY-OBJECT,  RIGHT  :  DISPLAY-OBJECT 
arcs 

REGION  ->  LEFT  :  import-morphism 

REGION  ->  RIGHT  :  import-morphism 

LEFT  ->  PAIR  :  {  Display-Object  ->  Left  } 

RIGHT  ->  PAIR  :  {  Display-Object  ->  Right  ) 

end-diagram 

by  {  LEFT. Display-Object  ->  Left-Display-Object, 

RIGHT. Display-Object  ->  Right-Display-Object  } 

spec  PAIR-OF-ADJ-DOS  is 

import  translate  PAIR-OF-DOS 
by  {  Pair-of-DOs  ->  Pair-of-Adj -DOs  ) 
axiom  (adj-x?  (extent  (left  p) )  (extent  (right  p) ) ) 
end- spec 

spec  DISPLAY-PAIR  is 

import  translate  colimit  of  diagram 
nodes  OBJECT,  PAIR,  DISPLAY-OBJECT 
arcs 

OBJECT  ->  PAIR  :  {  Object 

OBJECT  ->  DISPLAY- OBJECT  :  {  Object 
end-diagram 

by  {  Object  ->  Display- Pair  } 
end- spec 

spec  DISPLAY-PAIR-OF-DOS  is 

import  translate  colimit  of  diagram 
nodes  PAIR,  DISPLAY-PAIR,  PAIR-OF-DOs 
arcs 

PAIR  ->  DISPLAY-PAIR  :  {  Pair  ->  Display-Pair  } 
PAIR  ->  PAIR-OF-DOs  :  {  Pair  ->  Pair-of-DOs  } 
end-diagram 

by  {  Pair  ->  Display-Pair-of-DOs  } 
axiom  (contains  (extent  p)  (extent  (left  p) ) ) 
axiom  (contains  (extent  p)  (extent  (right  p) ) ) 
end- spec 


->  Pair  } 

->  Display-Object  } 
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spec  DISPLAY-PAIR-OF-ADJ-DOS  is 
translate  colimit  of  diagram 
nodes 

PAIR-OF-DOs,  DISPLAY-PAIR,  PAIR-OF-ADJ-DOs 
arcs 

PAIR-OF-DOs  ->  DISPLAY-PAIR  :  {  Pair-of-DOs  ->  Display- Pair  } 

PAIR-OF-DOs  ->  PAIR-OF-ADJ-DOS  :  {  Pair-of-DOs  ->  Pair-of-Adj -DOs  } 
end-diagram 

by  {  Pair-of-DOs  ->  Display-Pair-of-Adj -DOs  } 
end- spec 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
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Abstract.  Specware  supports  the  systematic  construction  of  formal  specifications 
and  their  stepwise  refinement  into  programs.  The  fundamental  operations  in  Specware 
are  that  of  composing  specifications  (via  colimits),  the  corresponding  refinement  by 
composing  refinements  (via  sheaves),  and  the  generation  of  programs  by  composing  code 
modules  (via  colimits).  The  concept  of  diagram  refinement  is  introduced  as  a  practical 
realization  of  composing  refinements  via  sheaves.  Sequential  and  parallel  composition  of 
refinements  satisfy  a  distributive  law  which  is  a  generalization  of  similar  compatibility 
laws  in  the  literature.  Specware  is  based  on  a  rich  categorical  framework  with  a  small 
set  of  orthogonal  concepts.  We  believe  that  this  formal  basis  will  enable  the  scaling  to 
system-level  software  construction. 
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1  Introduction 


Specware™  supports  the  systematic  construction  of  executable  programs  from  axiomatic 
specifications  via  stepwise  refinement.  The  immediate  motivation  for  the  the  development 
of  Specware  is  the  desire  to  integrate  on  a  common  conceptual  basis  the  capabilities  of 
several  earlier  systems  developed  at  Kestrel  Institute  [JiilligQS],  including  Kms  [Smith  90] 
and  Dtre  [Blaine  and  Goldberg  91]. 

1.1  Reasoning  about  the  Structure  of  Specifications,  Refinements, 
and  Code 

The  most  important  new  aspect  of  the  framework  developed  is  the  ability  to  represent  ex¬ 
plicitly  the  structure  of  specifications,  refinements,  and  program  modules.  We  believe  that 
the  explicit  representation  and  manipulation  of  structure  is  crucial  to  scaling  program  con¬ 
struction  techniques  to  system  development. 

The  basis  of  Specware  is  a  category  of  axiomatic  specifications  and  specification  mor- 
phisms.  Specification  structure  is  expressed  via  specification  diagrams,  directed  multi-graphs 
whose  nodes  are  labeled  with  specifications  and  arcs  with  specification  morphisms.  Specifi¬ 
cation  diagrams  are  useful  both  for  composing  specification  from  pieces  and  for  inducing  on 
a  given  specification  a  structure  suitable  for  the  design  task  at  hand. 

In  Specware  the  design  process  proceeds  by  stepwise  refinement  of  an  initial  specifica¬ 
tion  into  executable  code.  The  unit  of  refinement  is  an  interpretation,  a  theorem-preserving 
translation  of  the  vocabulairy  of  a  source  specification  into  the  terms  of  a  target  specification. 
Each  interpretation  reduces  the  problem  of  finding  a  realization  for  the  source  specification 
to  finding  a  realization  for  the  target  specification.  The  overall  result  of  the  design  process 
is  to  refine  an  initial  specification  into  a  program  module. 

Of  course,  it  is  desirable  to  structure  the  overall  refinement.  Progression  through  multiple 
stages  requires  sequential  composability  of  refinements.  Similarly,  parallel  composition  lets 
us  exploit  the  structure  of  specifications  by  putting  refinements  together  from  refinements 
between  sub-specifications  of  the  source  and  target  specifications.  It  is  for  this  purpose  that 
we  introduce  the  notion  of  diagram  refinements  in  this  paper:  just  as  specification  diagrams 
impose  a  component  structure  on  specifications,  so  do  diagram  refinements  make  explicit  the 
component  structure  of  a  specification  refinement. 

Specification  refinement  exploits  specification  structure;  code  generation,  in  turn,  exploits 
the  refinement  structure.  Given  translations  to  code  for  the  specifications  that  serve  as 
the  final  refinement  targets,  Specware  generates  a  system  of  modules  by  induction  on 
the  refinement  structure.  Layered  module  construction  mirrors  sequenticd  composition  of 
refinements,  aind  the  “gluing  together”  of  modules  into  larger  modules  reflects  the  (parallel) 
composition  of  specifications  and  refinements  from  components. 

Our  work  combines  ideas  and  notions  from  the  fields  of  algebraic  specifications,  category 
theory,  and  sheaf  theory.  We  believe  that  the  use  of  such  “heavy”  formal  machinery  is  well- 
justified.  For  instance,  category  theory  seems  ideally  suited  for  describing  the  manipulation  of 
richly  detailed  structures  at  various  levels  of  granularity.  Similarly,  the  sheaf-theoretic  notion 
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of  compatible  families  seems  fundamental  to  and  pervasive  in  putting  systems  together  from 
interdependent  components. 

The  ideas  and  concepts  presented  in  this  paper  have  been  implemented  in  the  Specware  1.0 
system,  which  continues  to  be  developed.  It  is  interesting  to  note  that  the  implementation 
efforts  seem  to  fare  the  better  the  more  closely  the  implementation  reflects  the  underlying 
theoretical  concepts.  Conversely,  experimentation  with  the  Specware  system  has  had  a 
significant  impact  on  the  theory  of  diagram  refinement  presented  here. 

1.2  Outline 

We  briefly  present  our  specification  language  in  Sect.  2  and  in  Appendix  A.  The  focus  of 
this  paper  is  the  sequential  and  parallel  composition  of  refinements,  as  described  in  Sect.  4. 
Sect.  5  discusses  how  sufficiently  refined  specifications  can  be  translated  to  programs.  Sect.  6 
describes  related  work.  Finally,  we  offer  some  conclusions  and  an  outlook  on  future  work. 


2  Putting  Specifications  Together 

The  primary  component  of  the  Specware  workspace  is  the  category  of  specifications  and 
specification  morphisms.  Diagrams  in  this  category  describe  system  structure.  Specifications 
can  be  put  together  via  colimits  to  obtain  more  complex  specifications.  We  will  only  briefly 
describe  these  concepts  because  these  ideas  are  well  known;  see,  e.g.,  [Burstall  and  Goguen  77, 
Sannella  and  Tarlecki  88a]. 

2.1  Specifications 

A  specification  is  a  finite  presentation  of  a  theory  in  higher-order  logic.  An  uncommon  fea¬ 
ture  of  Specware  is  that  subsorts  and  quotient  sorts  can  be  defined  using  predicates  and 
equivalence  relations,  respectively.  For  details  of  the  particular  logic  used,  see  Appendix  A. 

2.1.1  Specification-Constructing  Operations 

Specifications  can  either  be  directly  given  (as  a  set  of  sorts,  operations,  aodoms,  etc.)  or 
constructed  from  other  specifications  via  the  following  operations  (inspired  by  ASL  [Wirs- 
ing  86,  Sannella  and  Tarlecki  88a]) 

translate  (spec)  by  (renaming-rules) 
colimit  of  (diagram) 

spec  import  (spec)  (spec-elements)  end-spec 

“Translate”  creates  a  copy  of  a  specification  with  some  elements  renamed  according. to 
the  given  renamings;  am  isomorphism  is  adso  created  between  the  original  and  the  trans¬ 
lated  specifications.  “Colimit”  is  the  standaird  operation  from  category  theory  (see,  e.g., 
[Mac  Lane  71]);  colimits  axe  constructed  using  equivalence  classes  of  sorts,  operations,  etc. 
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“Import”  places  a  copy  of  the  imported  specification^  in  the  importing  specification;  an 
inclusion  morphism  is  also  generated. 

2.2  Specification  Morphisms 

A  specification  morphism  (or  simply  a  morphism)  translates  the  language  of  one  specification 
into  the  language  of  another  specification  in  a  way  that  preserves  theorems.  Specification 
morphisms  underlie  almost  all  constructions  in  Specware. 

2.2.1  Flavors  of  Specification  Morphisms 

The  set  of  sorts  given  in  a  specification  generates  a  free  algebra  via  sort-constructing  opera¬ 
tions  such  as  product,  coproduct,  etc.  A  specification  morphism  is  a  map  from  the  sorts^  and 
operations  of  one  specification  to  the  sorts  and  operations  of  another  such  that  (1)  the  map  is 
a  homomorphism  on  the  sort  algebras,  (2)  the  ranks  of  operations  are  translated  compatibly 
with  the  operations,  and  (3)  axioms  are  translated  to  theorems. 

A  presentation  of  a  specification  morphism  in  Specware  is  a  finite  map  from  the  declared 
sorts  in  the  source  specification  to  the  declared  or  constructed  sorts  in  the  target  specification, 
and  from  source  operations  to  target  operations,  such  that  the  map  generates  a  specification 
morphism  as  described  above. 

Many  fiavors  of  morphisms  can  be  defined  for  specifications,  ranging  from  axiom- 
preserving  presentation  morphisms  to  logical  morphisms  between  the  toposes  (theories)  gen¬ 
erated  by  the  source  and  target  specifications.  The  choice  made  in  Specware  (declared 
sorts  mapping  to  constructed  sorts)  is  a  pragmatic  one,  a  compromise  between  simplicity 
and  flexibility — morphisms  are  simple  enough  for  use  in  putting  specifications  together,  while 
flexible  enough  to  model  refinement. 

2.3  Specification  Diagrams 

A  morphism  from  A  to  B  may  be  construed  as  indicating  how  A  is  a  “part  of”  B.  Thus,  we 
can  use  morphisms  to  express  a  system  as  an  interconnection  of  its  parts,  i.e.,  as  a  diagram. 
Formally,  a  diagram  is  a  directed  multigraph  in  which  the  nodes  axe  labeled  by  specifications, 
and  the  edges  by  specification  morphisms  (in  a  multigraph,  there  can  be  more  than  one  edge 
between  any  two  nodes). ^ 

2.3.1  Composition  (Putting  Specifications  Together) 

We  can  reduce  a  diagram  of  specifications  to  a  single  specification  by  taking  the  colimit 
of  the  diagram.  The  colimit  of  a  diagrtim  is  constructed  by  first  taJhing  the  disjoint  union 
(coproduct)  of  all  the  specifications  in  the  diagram  and  then  the  quotient  of  this  coproduct 
via  the  equivalence  relation  generated  by  the  morphisms  in  the  diagram.  The  result  will  be 

^  Only  one  specification  can  be  imported.  .4  colimit  is  necessciry  if  multiple  specifications  axe  to  be  imported. 
•  Here,  we  take  “sorts'’  to  meein  all  the  sorts  in  the  sort  algebra. 

^  When  convenient,  we  will  treat  a  diagram  as  a  functor  from  the  category  freely  generated  by  its  underlying 
graph  to  the  category  of  specifications  and  specification  morphisms. 
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a  valid  specification  (i.e.,  the  colimit  exists)  only  if  the  sort  algebra  is  free  (this  means  that 
two  structurally  dissimilar  sorts  cannot  be  identified  in  a  colimit). 

Example  1.  The  specifications  for  topological  sorting  are  shown  in  Fig.  1  (following  Knuth 
[Knuth  68,  pp.  258-265]).  The  problem  of  topological  sorting  is  specified  as  an  input-output 
relation.  To  specify  this  relation,  we  need  the  concepts  of  partial  order  and  total  order 
on  some  set  of  elements;  these  specifications  are  first  put  together  via  a  colimit  and  then 
imported.  The  specification  for  partial  orders  contains  a  membership  predicate  and  a  less¬ 
or-equal  predicate  with  appropriate  axioms.  The  specification  for  total  orders  renames  the 
partial  orders  specification  and  extends  it  with  a  totality  axiom  and  a  less-than  predicate. 

In  the  figure,  the  arrow  labeled  “d”  is  a  definitional  extension  and  the  arrows  labeled  “c” 
are  part  of  a  colimit  cocone. 


3  Stepwise  Refinement 

The  development  process  of  Specware  is  intended  to  support  the  refinement  of  a  problem 
specification  into  a  solution  specification.  Refinements  introduce  additional  design  detail,  e.g., 
the  transformation  of  definitions  into  constructive  definitions,  representation  choices  for  data 
t3T)es,  etc.  Specware’s  refinement  constructs,  introduced  below,  address  three  important 
aspects  of  refinement: 

problem  reduction:  construction  of  a  solution  relative  to  some  base; 
stepwise  refinement:  sequential  composition  of  refinements;  and 
putting  refinements  together:  parallel  composition  of  refinements. 

3.1  Interpretations 

The  notion  of  refinement  in  Specware  is  that  a  specification  B  refines  a  specification  .4  if 
there  is  a  construction  which  produces  models  of  .4  from  models  of  B  [SaimeUa  and  Tair- 
lecki  88b].  Specification  morphisms  serve  this  purpose  because  associated  with  every  mor¬ 
phism  a  :  A  —>■  B  there  is  a  reduct  functor  _]„  which  produces  models  of  .4  from  models 
ofS.  Morphisms,  however,  are  too  weak  to  represent  refinements  which  normally  occur 
during  software  development.  So,  we  use  a  more  general  notion,  interpretations,  which  axe 
specification  morphisms  from  the  source  specification  to  a  definitional  extension  of  the  target 
specification. 

Definition!  (Interpretation).  An  interpretation  p  :  A  B  from  a  specification  A  (called 
domain  or  source)  to  a  specification  B  (called  codomain  or  target)  is  a  pair  of  morphisms 
A  A-as-B  <—  B  with  common  codomain  A-as-B  (czdled  mediating  specification  or  simply 
mediator),  such  that  the  morphism  from  B  to  .A-as-B  is  a  definitional  extension. 
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Fig.  1.  Specification  for  topological  sorting 


Definition  2  ( Definitional  extension) .  A  morphism  S  — >  T  is  a  strict  definitional  extension 
if  it  is  injective  and  if  every  element  ofT  which  is  outside  the  image  of  the  morphism  is 
either  a  defined  sort  or  a  defined  operation.  A  definitional  extension  is  a  strict  definitional 
extension  optionally  composed  with  a  specification  isomorphism. 

In  this  case,  we  also  sometimes  say  that  T  is  a  definitional  extension  of  S.  Definitional 
extensions  are  indicated  in  diagrams  by  — d-*-  . 

A  specification  and  any  definitional  extension  of  it  generate  the  same  topos  (or  theory). 
Hence,  interpretations  are  generali2ed  morphisms.  Interpretations  are  a  suitable  notion  of 
refinement  because  models  of  the  source  specification  can  be  constructed  from  models  of  the 
target  specification  by  first  expanding  them  along  the  definitional  extension  and  then  taking 
reducts. 

Example  2.  We  show  in  Fig.  2  an  interpretation  from  total  orders  to  sequences  in  which 
total  orders  are  represented  as  a  subsort  of  sequences:  a  sequence  represents  a  total  order 
if  and  only  if  it  does  not  contain  any  duplicate  elements.  This  subsort  is  defined  in  the 
mediating  specification.  Total-order  operations  are  then  defined  on  this  subsort  in  terms  of 
the  underlying  sequence  operations. 

In  general,  a  source  sort  may  be  represented  by  a  more  elaborately  constructed  sort.  For 
example,  partial  orders  can  be  represented  as  a  quotient  of  a  subsort  of  graphs:  to  qualify 
as  a  representative,  a  graph  must  be  acyclic  (this  is  the  subsort  predicate),  and  two  acyclic 
graphs  represent  the  same  partial  order  if  their  transitive  closure  is  the  same  (this  is  the 
equivalence  relation  for  the  quotient  sort). 

Interpretations  encompass  and  generalize  the  data  type  refinement  introduced  in  [Hoare  72] 
and  other  similar  schemes. 


3.2  Sequential  (Vertical)  Composition  of  Interpretations 

Given  two  interpretations  pi  :  A  B  and  p2  '  B  ^  C  such  that  the  codomain  of  the  first 
is  the  domain  of  the  second,  their  sequential  composition  p^o  pi'.  C  \s  obtained  as  in 
the  diagram  below  (the  marking  “po”  indicates  a  pushout  square). We  use  the  facts  that 
definitional  extensions  are  closed  under  composition  and  are  preserved  by  pushouts. 


Diagrams  axe  assumed  to  be  commutative  unless  stated  otherwise. 
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Fig.  2.  An  interpretation  of  total  orders  as  a  subsort  of  sequences 


Sequential  composition  of  interpretations  facilitates  incremental,  layered  refinement. 

3.3  Algorithm  Synthesis  and  Interpretation  Construction 

Algorithm  synthesis  plays  two  roles  in  the  model  of  software  development  supported  by 
SpECWARE: 

-  the  creation  of  constructive  definitions  in  interpretations,  and 

—  the  refinement  of  input-output  relations  sufficient  to  extract  a  constructively  defined 
function. 

Note  that  the  definitions  used  in  the  mediating  specification  of  an  interpretation  are  not 
required  to  be  constructive.  As  an  example,  see  the  definition  of  PRECEDES  in  the  specification 
TOTAL-ORDER-AS-SEQ  in  Fig.  2.  If  we  want  to  generate  code  corresponding  to  this  operation, 
then  we  have  to  further  refine  this  definition,  with  the  goal  of  replacing  the  existential 
quantifier  by  an  algorithm. 

Similarly,  the  input-output  relations  used  in  a  top-level  specification  are  not  usually 
functional.  As  an  exaimple,  see  the  definition  of  the  relation  TOPSORT  in  the  specification 
TOPOLQGICAL-SORTING  in  Fig.  1.  If  we  want  to  find  a  function  which  satisfies  this  relation, 
we  have  to  further  refine  the  enclosing  specification.  This  refinement  can  be  guided  by  a 
hierarchy  of  algorithm  theories  which  are  used  to  impose  additional  structure  on  the  speci¬ 
fication.  Details  of  this  process  can  be  found  in  [Smith  93,  Smith  and  Lowry  90]. 

Algorithm  synthesis  is  one  of  the  creative  parts  of  software  development  and  can  be  used 
to  construct  basic  interpretations  which  can  then  be  composed.  Specware  aids  this  by 
providing  a  scaffolding  which  takes  care  of  the  mundane  details,  thus  letting  the  developer 
identify  and  focus  on  the  creative  part. 


4  Putting  Refinements  Together 

Just  as  a  specification  can  be  put  together  from  smaller  specifications,  so  can  refinements 
of  a  specification  be  put  together  from  refinements  of  component  specifications.  Formally, 
the  various  ways  of  constructing  specifications  generate  a  Grothendieck  topology  on  the 
category  of  specifications  and  specification  morphisms,  and  refinements  form  a  sheaf  with 
respect  to  this  topology.  Introductions  to  Grothendieck  topologies  and  sheaves  can  be  found 
in  [Mac  Lane  and  Moerdijk  92],  [Artin  et  al.  72,  Exposes  I-IV);  an  application  to  algorithm 
derivation  and  several  computer  science  examples  can  be  found  in  [Srinivas  93]. 

4.1  Theoretical  Basis:  A  Sheaf  of  Refinements 

Definitions  {A  Topology  for  Specifications).  We  obtain  a  Grothendieck  topology  on  the 
category  of  specifications  and  specification  morphisms  by  defining  a  family  of  specification 
morphisms  {  5,-  — »■  5  }  with  common  codomain  to  be  a  covering  family  if  5  is  a  definitional 
extension  of  the  union  of  the  images  of  the  arrows  in  the  family. 


55 


Definition  4  {Image  of  a  Specification  Morphism).  The  image  of  a  specification  morphism 
a  :  S  -i-T  is  the  specification  consisting  of  all  elements  a{x)  where  x  is  any  element  of  the 
source  specification,  e.g.,  sort,  operation,  theorem,  etc. 

To  see  that  the  topology  above  encompasses  the  specification  constructing  operations 
of  Section  2.1.1,  observe  that  a  translation  generates  an  isomorphism  (which  is  a  singleton 
covering  family),  and  that  a  colimit  specification  is  covered  by  its  family  of  cocone  arrows. 
The  case  of  import  can  be  reduced  to  that  of  colimit.  However,  it  is  useful  to  distinguish 
the  case  when  the  import  morphism  is  a  definitional  e.xtension;  it  then  forms  a  (singleton) 
covering  family. 

Given  any  cover  for  a  specification,  a  refinement  for  the  specification  can  be  constructed 
from  refinements  for  the  elements  of  the  cover,  provided  the  refinements  are  “compatible”. 
This  observation  leads  to  a  sheaf. 

Definitions  {A  Sheaf  of  Refinements) .  Assume  a  fixed  specification  B,  the  base  specifica¬ 
tion.  Define  a  functor  TZ  :  Spec°P  — ^  Set  by  assiging  to  each  specification  S  the  set  of  all 
interpretations  (refinements)  from  S  to  B,  and  to  each  specification  morphism  m  :  S  T 
the  function  which  restricts  an  interpretation  p:T  B  to  ajx  interpretation  pom:  S  ^  B. 
This  functor  is  a  sheaf  with  respect  to  the  Grothendieck  topology  defined  above. 

The  sheaf  condition  asserts  that  for  every  cover  {  fi  :  Si  S  \  i  E  I},  every  compatible 
family  of  interpretations  {pi  :  Si  =>  B  \  i  E  1}  can  be  uniquely  extended  to  an  interpretation 
p  :  S  B  such  that  the  restriction  of  p  along  any  fi  is  equal  to  Pi. 

Informally,  a  family  of  interpretations  {pi :  Si  =>  B  \  i  E  1}  is  compatible  if  the  member 
interpretations  agree  wherever  the  pieces  of  the  cover  overlap.  In  this  case,  an  interpretation 
p  :  S  —>■  B  can  be  constructed  as  the  shared  union  of  the  given  family  of  interpretations. 
The  details  of  this  construction  will  be  omitted  here,  because  the  construction  is  similar  to 
the  parallel  composition  of  interpretations  described  below. 

4.2  Practical  Realization;  Diagram  Refinement 

Three  factors  prevent  a  direct  realization  of  the  sheaf- theoretic  view  of  putting  interpreta¬ 
tions  together  presented  in  the  previous  section:  (1)  The  compatibility  condition  is  hard  to 
check  because  pullbacks  do  not  exist  in  general  in  the  category  of  specification  morphisms; 
(2)  Equality  of  interpretations  is  hard  to  check;  (3)  It  is  unrealistic  to  assume  that  a  single 
base  specification  (the  refinement  target)  is  given.  Typically,  we  would  like  to  assemble  a 
target  specification  as  we  refine  pieces  of  the  source  specification. 

We  handle  (1)  by  using  only  those  covers  which  are  directly  given  by  specification  con¬ 
struction  operations.  In  particular,  a  (finite)  colimit  explicitly  indicates  the  shared  parts 
among  the  components  of  a  specification.  (2)  is  handled  by  introducing  interpretation  mor¬ 
phisms,  which  explicitly  indicate  how  one  interpretation  specializes  another.  We  also  use 
a  strong  equality  for  morphisms  which  can  be  checked  syntactically;  see  Definition  6  be¬ 
low.  (3)  is  handled  by  using  diagrams  in  the  category  of  interpretations  and  interpretation 
morphisms.  A  preliminary  target  specification  can  be  assembled  from  the  codomains  of  the 
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interpretations  in  a  diagram.  The  target  specification  can  be  further  modified  by  modifying 
the  diagram  of  specifications  that  defines  it. 

We  will  describe  these  concepts  below,  finally  obtaining  a  notion  of  refinement  for  dia¬ 
grams. 

Definition 6  {Strong  Morphism  Equality).  Two  specification  morphisms  cr,T  :  S  — +  T  are 
equal  if  for  each  sort  or  operation  x  e  S,  a{x)  =  t{x). 

Definition 7  {Interpretation  Morphism).  An  interpretation  morphism  from  an  interpreta¬ 
tion  Pi  :  Si  =>  Ti  to  another  interpretation  P2  :  S2=>  T2  is  a  triple  of  specification  morphisms 
such  that  the  diagram  on  the  right  below  commutes. 

■Si '  ">Ti  Si - *Si-as-Tf-ti — Ti 

II  III 

S2  '^T'2  S2 - *S2~0LS~T‘f-ti — 'T2 


Interpretations  and  interpretation  morphisms  form  a  category  Interp.  Another  view  of 
this  category  is  as  (a  sub-category  of)  the  functor  category  of  functors  from  •  ^  •  to 

the  category  Spec  of  specifications  and  specification  morphisms.  Hence,  colimits  in  Spec 
lift  to  colimits  in  the  category  of  interpretations.® 

Specifications,  interpretations,  and  interpretation  morphisms  form  a  double  category. 
That  is,  in  addition  to  the  obvious  sequential/vertical  composition  of  interpretation  mor¬ 
phisms,  there  is  also  a  parallel/horizontal  composition  of  interpretation  morphisms.  The  two 
compositions  satisfy  an  interchange  law:  given  six  interpretations  and  four  interpretation 
morphisms  as  shown  on  the  left  below,  the  equation  on  the  right  is  true. 


{P2  •  0:2)  o  {^1  •  ai)  =  {^2  o  /?i)  •  (0:2  o  tti) 


S2  •  >1/3 

Now,  given  two  specifications  which  are  defined  as  colimits,  a  compatible  family  of  in¬ 
terpretations  can  be  given  as  a  diagram  of  interpretations.  It  will  be  useful  here  to  treat 
diagrams  as  functors. 


Definitions  {Diagram  Refinement).  Given  two  diagrams  of  specifications  di  :  fy  — *>  Spec 
and  da  •  -^2  — *•  Spec,  a  diagram  refinement  {5,  a)  :  di  — *•  da  is  a  pair  consisting  of  a  diagram 
of  interpretations  5  :  fy  — >  Interp  with  shape  fy  and  a  functor  cr :  fy  — ►  /a  between  the  two 
shapes  such  that  the  following  diagram  commutes  (dom  eind  cod  are  the  obvious  functors 

®  Definitional  extensions  axe  preserved  by  colimits. 
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which  maps  interpretations  and  interpretation  morphisms  to  their  domains  and  codomains, 
respectively). 


h 


di 


d2 


Spec-t- —  Interp  — -^Spec 

dom  cod 


Example  3.  In  Fig.  3,  we  show  a  refinement  of  the  specification  for  topological  sorting  (shown 
in  Fig.  1):  the  partial  orders  are  refined  to  pairs  of  sequences  (one  listing  the  elements  and 
another  listing  the  ordering  relation),  and  the  total  orders  are  refined  to  sequences  (as  shown 
in  Fig.  2). 

The  components  of  the  colimit  which  defines  the  import  into  the  specification  for  topolog¬ 
ical  sorting  are  refined  in  parallel.  The  vertical  interpretations  emanating  from  this  diagram 
form  a  diagram  refinement.  Note  that  the  target  diagram  has  a  shape  which  is  different  from 
that  of  the  source  diagram;  the  extra  arrow  in  the  target  diagram  is  used  to  identify  the 
sequences  which  represent  the  elements  of  the  partial  orders  and  the  total  orders  (remember 
that  topological  sorting  takes  as  input  a  partial  order  and  produces  a  total  order  on  the  same 
set  of  elements). 
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Fig.  3.  Components  of  a  diagram  refinement 


4.2.1  Parallel  (Horizontcd)  Composition  of  Interpretations 

As  expected,  a  diagram  refinement  yields  a  refinement  from  the  colimit  of  the  source  diagram 
to  the  colimit  of  the  target  diagram.  Consider  the  diagram  refinement  (5,  a)  :  di  do  above. 
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Let  Si  and  52  be  the  colimits  of  the  two  diagrams.  The  colimit  of  the  interpretation  diagram 
6  is  an  interpretation  pi  :  5i  =4>-  5^  from  Si  to  the  colimit  (say  5^)  of  the  diagram  d2  o  cr  : 
Ii  Spec.  The  colimit  cocone  ^2  S2  when  composed  with  the  shape  morphism  a  gives 
a  cocone  d2  o  a  S2-  From  this,  we  obtain  a  witness  arrow  p2  :  5^  — *■  52.  The  composition 
P2  o  Pi  is  the  desired  parallel  composition  of  the  diagram  refinement  {5,a)  :  di  —>■  d2. 


diagrams 

di 

s  d2  0  (7  <7 

d2 

colimits 

c  _ 

.61 

Oi  — 

PI  2  p2 

-*-02 

We  will  denote  the  parallel  composition  of  a  diagram  refinement  by  |/\|. 

Example  4.  In  Fig.  4,  we  show  details  of  the  refinement  of  the  specification  for  topological 
sorting.  The  figure  illustrates  both  sequential  and  parallel  composition  of  interpretations.  As 
an  example  of  sequential  composition,  partial  orders  are  refined  to  pairs  of  sequences  by  rep¬ 
resenting  them  as  graphs;  the  graphs  are  then  represented  as  sets  of  nodes  and  sets  of  edges; 
then,  these  sets  are  represented  as  sequences.  There  are  also  several  parallel  compositions, 
e.g.,  the  refinements  of  Set-of-Paur  and  TS-Import. 

4.2.2  Composing  Diagram  Refinements 

Diagram  refinements  can  be  composed  by  composing  the  individual  interpretations  which 
comprise  them.  Let  {61,(71)  :  di  —*  d2  and  {62,(72)  :  ^2  “*■  ^3  be  two  diagram  refinements.  We 
can  juxtapose  these  as  shown  below. 


Spec-* —  Interp  — -*-Spec-»- —  Interp  — *-Spec 

Now,  as  shown  below,  we  get  two  diagrams  of  interpretations  with  shape  h,  namely 
and  62  o  cri,  such  that  the  codomcdns  of  the  interpretations  in  the  first  diagram  match 
with  the  domains  of  the  interpretations  in  the  second  diagram.  By  composing  the  individual 
interpretations,  we  get  another  interpretation  diagram  with  shape  Ii.  We  will  denote  this 
horizontally  composed  diagrcun  of  interpretations  by  (^2  o  cti)  •61.  The  shape  morphism  for 
the  composed  diagram  refinement  is  obtaiined  by  composing  the  individual  shape  morphisms, 
(72  o  cTi  :  — *•  /2  — ^  h.  Thus,.  ((^2  °  o-i)  •  5i,cr2  o  <7i)  \  di -*  dz  is  the  composition  of  the  two 

diagraim  refinements  we  started  with. 
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Fig.  4.  Refinement  of  topological  sorting 


<72  O  (7\ 


4.2.3  Compatibility  of  Vertical  eind  Horizontal  Interpretation  Composition 

If  zli  :  >  (^2  and  ^2’.  d2  dz  are  two  diagram  refinements  which  can  be  composed,  then 

the  distributive  law  satisfied  by  them  is 

[Ziol  O  l^ll  —  ®  '^l|- 
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This  can  be  verified  by  straighforward  diagram  chasing  (using  the  interchange  law  for  in¬ 
terpretation  morphisms).  Thus,  1_I  is  a  functor  from  the  category  of  diagrams  and  diagram 
refinements  to  the  category  of  specifications  and  interpretations. 

The  distributive  law  above  is  a  generalization  of  other  such  laws  introduced  in  the  lit¬ 
erature.  The  law  introduced  by  Goguen  and  Burstall  [Goguen  and  Burstall  80]  is  too  con¬ 
straining  to  be  practically  useful.  The  law  introduced  by  Sannella  and  Tarlecki  [Sannella  and 
Tarlecki  88b]  uses  parameterization  and  does  not  handle  colimits;  moreover,  it  is  semantically 
oriented. 


5  Putting  Code  Fragments  Together 

When  specifications  are  sufficiently  refined,  they  can  be  converted  into  programs  which  realize 
them.  This  involves  a  switching  of  logics.  We  use  the  theory  of  logic  morphisms  described 
by  Meseguer  [Meseguer  89].  We  will  confine  our  attention  to  entailment  systems  and  their 
morphisms,  rather  than  logics  (which  include  models  and  institutions).  Entailment  systems 
are  sufficient  for  the  purpose  of  code  generation. 

5.1  Entailment  Systems  and  their  Morphisms 

Definition  9  {Entailment  System).  An  entailment  system  is  a  triple  (Sig,  sen,  h)  consisting 
of 

1.  a  category  Sig  of  signatures  and  signature  morphisms, 

2.  a  functor  sen  :  Sig  — »■  Set  (where  Set  is  the  category  of  sets  and  functions)  which 
assigns  to  each  signature  E  the  set  of  i7-sentences,  and  to  each  signature  morphism 
a  ■.  E  E' ,  the  function  which  translates  i7-sentences  to  i7'-sentences  (this  function 
will  also  be  denoted  by  cr),  and 

3.  a  function  h  which  associates  to  each  signature  E  a  binary  relation  l-2;C  V{sen{E))  x 
sen{E),  called  i7-entailment, 

such  that  the  following  properties  are  satisfied: 

1.  reflexivity:  for  any  (p  €  sen{E),  {<^}  l-j;  <p; 

2.  monotonicity:  if  r\-s  and  F'  D  F,  then  F'  cp 

3.  transitivity:  if  Fh-^  <Pi,  for  i  €  I,  and  F  U  {(pi  \  i  E  I }  ip,  then  F  \-£  ip; 

4.  \- -translation:  if  F  (p,  then  for  any  signature  morphism  cr  :  E  E',  cr{F)  )r£>  cr{ip). 

To  map  one  entailment  system  into  another,  we  map  the  syntax  (i.e.,  signatures  and 
sentences)  while  preserving  entailment.  Preservation  of  entailment  represents  the  relevant 
correctness  criterion  for  translating  specifications  from  one  logic  to  another.  Note  that  this 
is  similar  to  the  correctness  criterion  for  refinement  within  a  single  logic. 
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A  simple  way  to  map  syntax  is  to  map  signatures  to  signatures,  and  sentences  over  a 
signature  to  sentences  over  the  translated  signature.  If  the  former  is  a  functor,  the  latter 
becomes  a  natural  transformation. 

Definition  10  {Entailment  system  morphism — plain  version).  A  morphism  between  entail- 
ment  systems  (^,  a)  :  (Sig,  sen,  h)  — >  (Sig',  sen',  K)  is  a  pair  consisting  of  a  functor  ^  : 
Sig  — >  Sig'  which  maps  signatures  to  signatures  and  a  natural  transformation  a  :  sen  -4 
sen'  o  which  maps  sentences  to  sentences  such  that  entailment  is  preserved; 

ocs{r)  oc£{p). 

We  can  visualize  a  and  the  naturality  condition  in  the  following  diagrams. 


Morphisms  which  map  signatures  to  signatures  are  not  flexible  enough,  especially  for 
code  generation.  In  general,  it  may  be  necessary  to  map  built-in  elements  of  one  logic  into 
defined  elements  of  another,  and  vice  versa.  This  can  be  realized  by  mapping  signatxires  to 
specifications,  and  vice  versa,  or,  in  general,  specifications  to  specifications. 

However,  morphisms  which  map  specifications  to  specifications  are  too  unconstrained.  So 
Meseguer  [Meseguer  89]  proposes  a  general  version  of  entailment  system  morphisms  which 
map  specifications  to  specifications  “sensibly”.  We  will  use  these  morphisms  but  omit  the 
detailed  definition  here. 


5.2  'Translating  from  Slang  to  Lisp 

The  specification  language  used  in  Specware  is  called  Slang.  We  distinguish  Slang  be¬ 
cause  Specware  may  have  multiple  back-ends.  Lisp,  C,  Ada,  etc.,  each  with  its  own  logic. 

We  consider  a  sub-logic  of  Slang,  called  the  abstract  target  language  (for  LiSP);  there  is 
one  sub-logic  for  each  language  into  which  Slang  specifications  can  be  translated.  We  will 
denote  this  sub-logic  by  Slang  .  The  sub-logic  Slang  is  defined  by  starting  with  a  set 
of  basic  specifications,  such  as  integers,  sequences,  etc.,  which  have  direct  realizations  in  the 
target  language.  All  specifications  which  can  be  constructed  from  the  base  specifications, 
with  the  following  restrictions,  are  then  included  in  the  sub-logic: 

—  for  colimit  specifications,  only  injective  morphisms  are  allowed  in  the  diagram;® 

®  For  colimit  specifications  which  can  be  construed  as  “instantiations”  of  a  “generic”  specification,  the 
morphisms  from  the  formal  to  the  actual  may  be  non-injective. 
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-  all  definitions  must  be  constructive,  i.e.,  they  must  either  be  explicit  definitions  (e.g., 
(equal  (square  x)  (times  x  x))),  or,  if  they  are  recursive,  they  must  be  given  as 
conditional  equations  using  a  constructor  set. 

The  goal  of  the  refinement  process  is  to  arrive  at  a  sufficiently  detailed  specification  which 
satisfies  the  restrictions  above. 

The  sub-logic  Slang —  will  be  translated  into  a  functional  subset  of  LiSP.  To  facilitate 
this  translation,  we  couch  this  subset  as  an  entailment  system,  denoted  LiSP““.  The  signa¬ 
tures  of  this  entailment  system  are  finite  sets  of  untyped  operations  and  the  sentences  are 
function  definitions  of  the  form 

(defun  f  (x) 

(cond  ((p  x)  (g  x)) 

...)) 

and  generated  conditional  equations  of  the  form 
(if  (p  x)  (equal  (f  x)  (g  x))). 

The  entailment  relation  is  that  of  rewriting,  since  theories  in  LiSP  can  be  viewed  as 
conditional-equational  theories  over  the  simply-typed  A-calculus. 

In  Fig.  5,  we  show  a  fragment  of  an  entailment  system  morphism  from  Slang  to 
Lisp — .  Note,  in  particular,  the  translations  from  and  to  empty  specifications.  The  set  of 
sentences  in  the  Slang  specification  INT  translates  to  the  empty  set;  this  is  because  integers 
are  primitive  in  LiSP.  Similarly,  the  empty  SLANG  specification  translates  to  a  non-empty 
Lisp  specification;  this  is  because  some  built-in  operations  of  Slang  are  not  primitive  in 
Lisp. 

5.2.1  Translating  Constructed  Sorts 

There  are  numerous  details  in  entailment  system  morphisms  such  as  that  from  Slang 
to  Lisp — .  We  will  briefly  consider  the  translation  of  constructed  sorts.  Subsorts  can  be 
handled  by  representing  elements  of  a  subsort  by  the  corresponding  elements  of  the  supersort. 
Similarly,  quotient  sorts  can  be  handled  by  representing  their  elements  by  the  elements  of 
the  base  sort.  Sentences  have  to  be  translated  consistently  with  such  representation  choices: 
e.g.,  injections  associated  with  subsorts  ((relax  p))  and  the  surjections  associated  with 
quotient  sorts  ((quotient  e))  must  be  dropped.  Also,  the  equality  on  a  quotient  sort  must 
be  replaced  by  the  equivalence  relation  defining  the  quotient  sort. 

In  Fig.  6,  we  show  the  representation  of  coproduct  sorts  by  variant  records.  This  trans¬ 
lation  exploits  the  generality  of  entailment  system  morphisms:  a  signature  is  mapped  into  a 
theory. 

5.3  Translation  of  Colimits:  Putting  Code  Fragments  Together 

If  an  entailment  system  morphism  is  defined  in  such  a  way  that  it  is  co-continuous,  i.e., 
colimits  are  preserved,  then  we  obtain  a  recursive  procedure  for  translation,  which  is  sinnilar 
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Sla.ng 

— »■  Lisp 

EMPTY 

1 — >  spec  SLANG-BASE  is 

ops  implies,  iff 
(defun  implies  (x  y) 

(or  (not  x)  y)) 

(defun  iff  (x  y) 

(or  (and  x  y) 

(and  (not  x)  (not  y)))) 
end-spec _ 


INT 

1 — ^  SLANG-BASE 

spec  FOO  is 

1 — ••  spec  FOO’  is 

import  INT 

import  SLANG-BASE 

op  abs  :  Int  ->  Int 

op  abs 

definition  of  abs  is 

(defun  abs  (x) 

axiom 

(cond  ((>=  X  0)  x) 

(implies  (ge  x  zero) 

(«  X  0)  (-0  x)))) 

(equal  (abs  x)  x)) 
axiom 

(implies  (It  x  zero) 

(equal  (abs  x)  (minus  zero  x))) 
end-def init ion 
end-spec 

end- spec 

Fig.  5.  Fragment  of  entailment  system  morphism  from  Slang —  to  LiSP — 


spec  STACK  is 
import  INT 

sort-axiom 

Stack  =  E-Stack  +  ME-Stack 

op  size  :  Stack  ->  Int 
definition  of  size  is 
axiom 

(equal  (size  ((embed  1)  s)) 
zero) 

axiom 

(equal  (size  ((embed  2)  s)) 

(succ  (size  (pop  s)))) 
end-definition 
end-spec 


spec  STACK’  is 
import  SLANG-BASE 
op  size,  E-Stack?,  NE-Stack? 
(defun  E-Stack?  (s) 

(=  (car  s)  1)) 

(defun  size  (s) 

(cond 

((E-Stack?  s)  0) 

((NE-Stack?  s) 

(1+  (size  (pop  (cdr  s))))) 

)) 

end-definition 
end- spec 


Fig.  6.  The  representation  of  coproduct  sorts  as  variant  records 
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to  that  of  refinement:  the  code  for  a  specification  can  be  obtained  by  assembling  the  code 
for  smaller  specifications  which  cover  it. 

The  entailment  system  morphism  from  Slang  to  Lisp  briefly  described  above  does 
preserve  colimits  because  of  our  restriction  to  injective  morphisms.  In  general,  this  is  true 
for  most  programming  languages  because  they  only  allow  imports,  which  are  inclusion  mor¬ 
phisms. 


6  Related  Work 

Specware  builds  upon  a  large  body  of  work  in  formal  specifications  and  program  synthesis 
and  transformation  developed  over  the  last  two  decades. 

The  design  of  Slang,  the  specification  language  of  Specware,  was  inspired  by  Sanella 
and  Tarlecki’s  [Sannella  and  Tarlecki  88a|  and  Wirsing’s  work  [Wirsing  86]  on  structured 
algebraic  specifications.  Putting  theories  together  via  colimits  was  first  proposed  by  Burstall 
and  Goguen  as  part  of  Clear  [Burstall  and  Goguen  77).  Slang  was  further  influenced  by 
CiP  [Bauer  et  al.  85,  Bauer  et  al.  87]  and  OBJ  [Goguen  and  Winkler  88]. 

Specware  adopts  in  a  higher-order  setting  the  notion  of  interpretations  as  refinements 
from  Turski’s  and  Maibaum’s  development  in  first-order  logic  [Turski  and  Maibaum87]. 
Specware  could  be  construed  as  a  realization  of  the  design  methodology  espoused  by 
Lehman,  Stenning,  and  Turski,  with  the  addition  of  parallel  refinement  composition  [Lehman 
et  al.  84].  The  notion  of  parallel  refinement  composition  described  in  this  paper  is  different 
from  the  horizontal  composition  of  parameterized  specifications  described  by  Saimella  and 
Tarlecki  [Sannella  and  Tarlecki  88b]. 

The  explicit  use  of  subsort  and  quotient  sort  constructions  in  Specware  connects  data 
type  refinement  in  an  algebraic  setting  with  Hoare’s  abstraction/refinement  functions  [Hoare  72] 
which  also  underlie  the  refinement  found  in  Vdm  [Jones  86]. 

Our  work  is  both  similax  and  complementary  to  Bird’s  and  Meertens’  equational  rea¬ 
soning  approach  to  program  development  [Bird  86,  Bird  87].  Reasoning  about  commuting 
specification  diagrams  is  equational  reasoning  at  the  specification  level;  Bird’s  and  Meertens’ 
equations  are  at  the  etxiom  level.  Of  course  the  two  can  happily  co-exist. 

Om:  framework  for  structured  code  generation  is  adopted  from  Meseguer’s  work  on  logic 
morphisms  [Meseguer  89]. 

The  direct  impetus  to  the  development  of  Specware  came  firom  the  desire  to  integrate 
several  systems  developed  at  Kestrel  Institute  over  the  last  ten  years,  and  the  realization  that 
they  shared  a  common  conceptual  basis.  These  include  the  edgorithm  design  system  Kids 
[Smith  90],  the  data  type  refinement  system  Dtre  [Blaine  and  Goldberg  91],  Reacto,  a 
system  for  the  development  of  reactive  systems  [Gilheun  et  3il.  89],  and  a  synthesis  system 
for  visual  presentations  [Green  87].  An  overview  is  presented  in  [JuUig  93]. 
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Conclusions 


7.1  Summary 

We  presented  the  specification  and  refinement  concepts  of  Specware,  a  system  aimed  at 
supporting  the  application  of  formal  methods  to  system  development.  Specware  draws  on 
theoretical  work  in  formal  specification  and  program  synthesis  as  well  as  on  experience 
with  experimental  systems  over  the  past  two  decades.  The  development  of  Specware  con¬ 
tinues;  however,  all  concepts  introduced  here  have  been  implemented.  We  have  found  the 
co-development  of  theory  and  implementation  mutually  beneficial. 

The  basic  specification  concepts  of  Specware  are  specifications,  specification  morphisms, 
and  diagrams  of  specifications  and  specification  morphisms.  The  colimit  operation  takes 
diagrams  of  specifications  to  specifications. 

The  basic  refinement  notion  is  an  interpretation,  a  morphism  from  a  source  specifica¬ 
tion  into  a  definitional  extension  of  a  target  specification.  Interpretations  are  closed  under 
sequential  composition.  To  arrive  at  a  notion  of  parallel  refinement  composition,  we  first 
observed  that  colimits  and  definitional  extensions  generate  a  Grothendieck  topology  on  the 
category  of  specifications  and  specification  morphisms,  and  that  refinements  form  a  sheaf 
with  respect  to  this  topology.  Essentially  this  means  that  that  given  a  specification  diagram 
and  an  assignment  of  an  interpretation  to  each  node  in  the  diagram  one  can  construct  an 
interpretation  for  the  colimit  of  the  given  specification  diagram,  provided  the  compatibility 
condition  holds:  the  interpretations  assigned  to  the  nodes  must  agree  on  shared  parts. 

The  difficulty  of  checking  the  compatibility  condition,  among  other  reasons,  prevented  the 
direct  application  of  this  theory  in  practice.  We  instead  developed  diagram  refinements  as  a 
practical  realization;  in  diagram  refinements  the  compatibility  of  interpretations  is  explicity 
ensured  by  the  presence  of  interpretation  morphisms. 

7.2  Future  Work 

Current  work  includes  adding  to  Specware  parameterized  specifications  and  interpretations 
of  parameterized  specifications.  This  will  lead  to  a  vertical  composition  similar  to  that  of 
Saimella’s  and  Tarlecki’s  [Sannella  and  Tarlecki  88b]  but  to  a  different  horizontal  composition 
notion. 

With  the  addition  of  parameterized  specifications  Specware  contains  a  set  of  primitives 
rich  enough  to  allow  for  substantial  experimentation.  For  this  purpose  we  will  recreate  the 
algorithm  design  capabilities  of  Kids  in  Specware.  We  also  expect  the  addition  of  code 
generation  to  other  programming  languages  in  addition  to  Lisp. 
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A  The  Logic  of  Slang 

The  specification  language  used  in  Specware  is  called  Slang.  We  distinguish  Slang  be¬ 
cause  Specware  may  have  multiple  back-ends,  Lisp,  C,  Ada,  etc.,  each  with  its  own  logic. 

Slang  is  based  on  higher-order  logic,  or  higher-order  type  theory,  as  described  in  [Lam- 
bek  and  Scott  86].  However,  unlike  Lambek  and  Scott,  we  use  classical  logic  (rather  than 
intuitionistic  logic)  because  the  theorem  prover  currently  used  in  Specware  is  a  resolution 
prover  based  on  classical  first-order  logic  (with  some  higher-order  facilities). 

Logically  speaking,  a  Slang  specification  is  a  finite  collection  of  sorts,  operations,  and 
theorems  (some  of  which  are  axioms).  For  pragmatic  reasons,  we  have  added  sort-axioms 
(which  are  currently  used  to  name  sort  terms),  constructor  sets  (which  are  equivalent  to 
induction  axioms),  and  definitions  (which  are  sets  of  axioms  characterizing  new  operation 
symbols). 

Every  SLANG  specification  can  be  freely  completed  to  a  topos  (see  [Lambek  and  Scott  86, 
Section  11.12]  for  a  description  of  this  construction).  The  objects  in  this  topos  are  all  sorts 
definable  in  the  specification;  the  arrows  are  all  definable  operations  (i.e.,  provably  functional 
relations). 

Built-in  Constructs 

The  only  sort  which  is  built-in,  i.e.,  is  implicitly  part  of  every  specification,  is  Boolean.  Along 
with  this  sort,  the  standard  operations  on  it  such  as  true,  false,  and,  or,  etc.,  and  axioms 
characterizing  them  are  built-in.  The  universal  (fa)  and  existential  (ex)  quantifiers,  and  a 
polymorphic  equality  (equal)  are  also  built-in. 

Sort  Constructors 

Lambek  and  Scott  adopt  a  minimal  set  of  sort  constructors.  While  this  is  theoretically 
economical,  we  have  chosen  a  richer  set  of  sort  constructors  which  arise  in  practice,  especially 
in  interpretations.  We  will  use  the  generated  topos  to  characterize  these  sort  constructors; 
it  is  straightforward  to  generate  the  corresponding  axioms. 

N-eiry  products  and  coproducts.  Given  a  set  of  n  sorts,  their  product  and  coproduct  are 
sorts  which  come  equipped  with  the  normcd  projections  and  embeddings,  and  characterized 
by  the  usual  universal  property. 


A-1 


A-n 


A-1 


A-n 


(project  /project  n) 

A-1, . . - ,A-a 


(embed  y^embed  a) 

A-1+. . .+A-U 


Function  sorts.  Given  two  sorts  A  and  B,  the  function  sort  from  A  to  B,  written  A  ->  B, 
satisfies  the  usual  universal  property  and  comes  equipped  with  an  evaluation  operation,  writ¬ 
ten  (<rator>  <ap>),  and  an  abstraction  operation,  written  (lambda  (<args>)  <body>). 
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Subsorts.  Given  a  sort  A  and  a  predicate  op  p:  A  ->  Boolean  on  this  sort,  the  subsort 
of  A  consisting  of  those  elements  which  satisfy  the  predicate,  written  A I  p,  and  the  induced 
injection  are  characterized  by  the  following  pullback  diagram  (1  is  the  terminal  object,  and 
!  denotes  the  unique  arrow  into  it  from  Alp). 


(relaix  p) 

I  > - ^A 


Boolean 


Quotient  sorts.  Given  a  sort  A  and  an  equivalence  relation  op  e :  A,A  ->  Boolean  on  this 
sort,  the  quotient  sort  consisting  of  equivalence  classes  of  elements  of  A,  written  A/e,  and  the 
induced  surjection  are  characterized  by  the  following  coequalizer  diagram  ((A,A)  |e  is  the 
equivalence  relation  as  a  subsort  of  A, A). 


(A,  A)|e 


(project  l)o (relax  e) 

*  A 

(project  2)  0  (relax  e) 


(quotient  e)  , 

- »-A/e 


Sort  Axioms 

Sort  axioms  are  equations  between  sorts.  Currently,  these  are  restricted  so  that  the  left- 
hand  side  is  a  primitive  sort  (i.e.,  a  sort  which  is  not  constructed  using  one  of  the  sort 
constructors).  Thus,  in  effect,  sort  axioms  create  new  names  for  sorts.  This  keeps  the  sort 
algebra  free,  which  is  convenient  for  the  type-checker.  In  the  future,  we  may  allow  non-free 
sort  algebras,  and  extend  the  type-checker  to  handle  this. 

Constructor  Sets 


A  constructor  set  for  a  sort  is  a  finite  set  of  operations  with  that  sort  as  the  codomain.  A 
constructor  set  is  equivalent  to  an  induction  aixiom.  Here  is  em  exaimple. 


constructors  {zero,  one,  plus}  construct  NAT 


axiom  induction-for-NAT  is 
(fa  (P)  (implies 

(and  (and  (P  zero)  (P  one)) 

(fa  (x  y)  (implies  (and  (P  x)  (P  y)) 

(P  (plus  X  y))))) 

(fa  (n)  (P  n)))) 

Note  that  a  constructor  set  need  not  freely  generate  the  constructed  sort,  i.e.,  the  images  of 
the  constructors  need  not  be  disjoint.  Additional  axioms  are  necessary  to  force  this. 
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Definitions 


Definitions  in  Slang  are  finite  sets  of  axioms  which  completely  characterize  an  operation. 
What  this  means  is  that  to  define  a  new  operation  f :  A  ->  B  in  a  specification  5,  there 
must  be  a  formula  phi  with  exactly  two  free  variables  x :  A  and  y :  B  such  that  the  relation 
specified  by  phi  is  provably  functional  in  S: 

(and  (fa  (x)  (ex  (y)  (phi  x  y))) 

(fa  (x)  (implies  (and  (phi  x  yl)  (phi  x  y2)) 

(equal  yl  y2)))) 

Then  S  can  be  extended  with  the  operation  f  together  with  the  defining  axiom 
(iff  (equal  (f  x)  y)  (phi  x  y)). 
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